www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Render SVG To Display And Update Periodically

reply Jason C. Wells <example example.com> writes:
I have in mind a project to render instruments (speed, pressure, 
position) to a screen using SVG. I am able to produce the SVG 
easily enough. What I am looking for is a library/canvas/toolkit 
that I can use in D inside of a loop and update the instrument 
readouts.

This whole project is a vehicle for me to expand my mechanical 
engineering abilities into instrumentation and control. I've 
decided that D is the language I want to learn to do this.

I see things like Cairo and librsvg. Maybe a full blown GUI 
toolkit has the bits i need. The thing I have a hard time with is 
assessing whether or not these things are suitable for what I 
hope to do.

Thanks in advance,
Jason C. Wells
Oct 16 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 17/10/2016 2:20 PM, Jason C. Wells wrote:

 I have in mind a project to render instruments (speed, pressure,
 position) to a screen using SVG. I am able to produce the SVG easily
 enough. What I am looking for is a library/canvas/toolkit that I can use
 in D inside of a loop and update the instrument readouts.

 This whole project is a vehicle for me to expand my mechanical
 engineering abilities into instrumentation and control. I've decided
 that D is the language I want to learn to do this.

 I see things like Cairo and librsvg. Maybe a full blown GUI toolkit has
 the bits i need. The thing I have a hard time with is assessing whether
 or not these things are suitable for what I hope to do.

 Thanks in advance,
 Jason C. Wells


You're going to need to find an svg rasterizer in some form or another.
I don't think we have one in D and certainly not a complete one.

Otherwise you could always just make it as web application and let the 
web browser do all the rendering, which seems easier.
Oct 16 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole 
wrote:

 You're going to need to find an svg rasterizer in some form or 
 another.
 I don't think we have one in D and certainly not a complete one.


'cmon, you know that i have a working port of NanoSVG! and it 
works on top of NanoVG, so no toolkit is required. ah...
Oct 17 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote:

 On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole 
 wrote:

 You're going to need to find an svg rasterizer in some form or 
 another.
 I don't think we have one in D and certainly not a complete 
 one.


 'cmon, you know that i have a working port of NanoSVG! and it 
 works on top of NanoVG, so no toolkit is required. ah...


oops, forgot to give some links. ;-)

nanovg and nanosvg ports: 
http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg
some demos: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo

to make it actually draw something, i'm using Adam's excellect 
simpledisplay from here: https://github.com/adamdruppe/arsd

fetching color.d and simpledisplay.d is enough, you don't need 
the whole repository. ;-)

it works at least in GNU/Linux and Windows. OSX is not tested.
Oct 17 2016
parent reply Karabuta <karabutaworld gmail.com> writes:
On Monday, 17 October 2016 at 07:18:40 UTC, ketmar wrote:

 On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote:

 On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole 
 wrote:

 [...]


 'cmon, you know that i have a working port of NanoSVG! and it 
 works on top of NanoVG, so no toolkit is required. ah...


 oops, forgot to give some links. ;-)

 nanovg and nanosvg ports: 
 http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg
 some demos: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo

 to make it actually draw something, i'm using Adam's excellect 
 simpledisplay from here: https://github.com/adamdruppe/arsd

 fetching color.d and simpledisplay.d is enough, you don't need 
 the whole repository. ;-)

 it works at least in GNU/Linux and Windows. OSX is not tested.


This thing really needs a GitHub repo + documentation after all 
the hardwork.
Oct 18 2016
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 18 October 2016 at 21:00:12 UTC, Karabuta wrote:

 On Monday, 17 October 2016 at 07:18:40 UTC, ketmar wrote:

 On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote:

 [...]


 oops, forgot to give some links. ;-)

 nanovg and nanosvg ports: 
 http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg
 some demos: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo

 to make it actually draw something, i'm using Adam's excellect 
 simpledisplay from here: https://github.com/adamdruppe/arsd

 fetching color.d and simpledisplay.d is enough, you don't need 
 the whole repository. ;-)

 it works at least in GNU/Linux and Windows. OSX is not tested.


 This thing really needs a GitHub repo + documentation after all 
 the hardwork.


https://github.com/Pctg-x8/nanovg-d, I even think it's been 
announced here last year.
Oct 18 2016
next sibling parent reply Jason C. Wells <example example.com> writes:
This is probably a general programming question. I'll follow up 
here since this thread is the inspiration for my current question.

When attempting to compile simpledisplay.d, I get the following:

C:\...\dlang\arsd-master>dmd -Lgdi32.lib -L user32.lib 
simpledisplay.d color.d
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : NOIGDI32.LIBUSER32.LIB
simpledisplay.obj(simpledisplay)
  Error 42: Symbol Undefined _D9invariant12_d_invariantFC6ObjectZv
simpledisplay.obj(simpledisplay)
** snip **

Interestingly enough, simpledisplay.obj and simpledisplay.exe are 
produced. Aren't errors fatal? The EXE is not a valid win32 
application.

I am used to makefiles. The author doesn't use dub for these 
programs. (dub ~=make?)

gdi32.lib and user32.lib appear in multiple directories.  I added 
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64" to 
%LIB% which seemed sensible to do. I still get the warning:

OPTLINK : Warning 9: Unknown Option : NOIGDI32.LIBUSER32.LIB

So, I'm still figuring out how to set up a compile. I presume 
that dmd is not finding gdi32.lib and user32.lib.  What am I 
missing?

Regards,
Jason C. Wells
Oct 19 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 20 October 2016 at 04:52:11 UTC, Jason C. Wells 
wrote:

 This is probably a general programming question. I'll follow up 
 here since this thread is the inspiration for my current 
 question.

 When attempting to compile simpledisplay.d, I get the following:

 C:\...\dlang\arsd-master>dmd -Lgdi32.lib -L user32.lib 
 simpledisplay.d color.d


Don't pass libraries with -L. Just do it like this:

dmd gdi32.lib user32.lib



 Interestingly enough, simpledisplay.obj and simpledisplay.exe 
 are produced. Aren't errors fatal? The EXE is not a valid win32 
 application.


Those aren't errors. The linker thinks it has been passed a 
couple of options that it doesn't understand, but it will still 
proceed with the link.


 I am used to makefiles. The author doesn't use dub for these 
 programs. (dub ~=make?)

 gdi32.lib and user32.lib appear in multiple directories.  I 
 added "C:\Program Files (x86)\Windows 
 Kits\8.1\Lib\winv6.3\um\x64" to %LIB% which seemed sensible to 
 do. I still get the warning:

 OPTLINK : Warning 9: Unknown Option : NOIGDI32.LIBUSER32.LIB


See that OPTLINK in the error messages? That's the Digital Mars 
linker that ships with DMD. It doesn't know anything at all about 
the libraries that ship with the Windows kits. It uses the 
libraries that ship with DMD. The Windows SDK is only used when 
using the Microsoft linker, which only happens when passing -m64 
or -m32mscoff to the compiler. By default (-m32), DMD uses 
OPTLINK.

Again, just pass the libraries without -L.


 So, I'm still figuring out how to set up a compile. I presume 
 that dmd is not finding gdi32.lib and user32.lib.  What am I 
 missing?


Your bigger issue, and why your compilation didn't produce a 
valid executable, is that you have no main function! Try 
something like the following:

Directory tree:
- testapp
-- test1.d
--- arsd
---- simpledisplay.d
---- color.d

In test1.d, using an example copy/pasted from the simpledisplay.d 
ddoc comments:

```
import arsd.simpledisplay;
import std.conv;
void main() {
     auto window = new SimpleWindow(Size(500, 500), "My D App");
     int y = 0;
     void addLine(string text) {
         auto painter = window.draw();
         if(y + painter.fontHeight >= window.height) {
             painter.scrollArea(Point(0, 0), window.width, 
window.height, 0, painter.fontHeight);
             y -= painter.fontHeight;
         }
         painter.outlineColor = Color.red;
         painter.fillColor = Color.black;
         painter.drawRectangle(Point(0, y), window.width, 
painter.fontHeight);
         painter.outlineColor = Color.white;
         painter.drawText(Point(10, y), text);
         y += painter.fontHeight;
     }
     window.eventLoop(1000,
       () {
         addLine("Timer went off!");
       },
       (KeyEvent event) {
         addLine(to!string(event));
       },
       (MouseEvent event) {
         addLine(to!string(event));
       },
       (dchar ch) {
         addLine(to!string(ch));
       }
     );
}
```

Then run the compiler with:

dmd test1.d arsd/simpledisplay.d arsd/color.d gdi32.lib user32.lib

IIRC, you don't need to pass user32.lib, as DMD will link it in 
by default (though I may be mistaken).
Oct 20 2016
parent reply Jason C. Wells <example example.com> writes:
I've tinkered with what you proposed. In the process I've worked 
through a variety of errors and ended up doing things I don't 
think are a good solution like duplication directories so that a 
library can be found.

Let me see if I understand how to piece together a build. Some 
combination of three things need to be in agreement:

1 - the import statements need to point to a matching directory 
structure
2 - the directory structure needs to be arranged such that the 
imports can be found
3 - the compiler can be told directly on the command line where 
imports are

I'm reading 
https://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows 
which seems to be the document I need to sort through this.

I'll close out with this last question and then go study up. Am I 
barking up the right tree?
Oct 21 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 21 October 2016 at 23:16:55 UTC, Jason C. Wells wrote:

 I've tinkered with what you proposed. In the process I've 
 worked through a variety of errors and ended up doing things I 
 don't think are a good solution like duplication directories so 
 that a library can be found.

 Let me see if I understand how to piece together a build. Some 
 combination of three things need to be in agreement:

 1 - the import statements need to point to a matching directory 
 structure
 2 - the directory structure needs to be arranged such that the 
 imports can be found
 3 - the compiler can be told directly on the command line where 
 imports are

 I'm reading 
 https://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows which seems
to be the document I need to sort through this.

 I'll close out with this last question and then go study up. Am 
 I barking up the right tree?


Yes. The compiler needs to know where to find the imports you use 
in the form of D source files or import modules (.di). 
Additionally, the linker needs to know which object files or 
libraries it needs to combine with your compiled source to create 
the executable, be they generated from D code or C or C++, and 
where to find them.

By default, the compiler knows where to find the Phobos and 
DRuntime modules and also that it needs to pass phobos.lib (which 
also includes the DRuntime objects) to the linker, so you never 
have to specify those. Any other modules you import besides your 
own need to be handled in one of the following ways:

* They can be passed directly to the compiler along with your own 
source. This will cause them to be compiled and ultimately linked 
into the resulting binary.

* The compiler can be told where to find the source to those 
modules with the -I command line switch. This *does not* cause 
them to be compiled. The compiler will only parse them when one 
is imported so that it can determine which symbols are available 
in the module it is currently compiling. You will still need to 
ensure those third-party modules are compiled separately and 
given to the linker.

Here's are a couple examples of the second approach, using the 
following directory structure:

- libraries
-- import
--- arsd
---- color.d
---- terminal.d
-- lib
- myprojects
-- foo
--- foo.d

Since Adam doesn't package the arsd stuff as a lib, you'll need 
to compile them yourself.

cd libraries
dmd -lib arsd/color.d arsd/terminal.d -odlib -ofarsd.lib

The -lib switch tells the compiler to create a library after it 
has compiled the files. The -od switch tells it to write the 
library in the lib directory and -od says the file name should be 
arsd.lib. This will result in the file libraries/lib/arsd.lib.

Alternatively, you could do this:

dmd arsd/color.d arsd/terminal.d -odlib

This will create lib/color.obj and lib/terminal.obj. It's easier 
to just create the library, which is an archive of both object 
files.

If you intend to use the Visual Studio linker, you will need to 
ensure you compile the library with the same flags you will use 
to compile the program (-m64 or -m32mscoff).

Now, assuming foo.d is the same code from my last post, cd into 
the myprojects/foo directory and do the following:

dmd -I../../import foo.d ../../lib/arsd.lib gdi32.lib user32.lib

The -I switch tells the compiler where it can find imports. It 
should always be the parent directory of the *package* you want 
to import. In this case, the package is arsd. A common mistake is 
to give import/arsd to the compiler.

In this case, I've passed the full path to the library because 
that's the easiest thing to do on Windows. It's possible to tell 
the linker which path to look in by using DMD's -L switch (which 
passes options directly to the linker), but OPTLINK and the MS 
linker use different switches for that. It's simpler just to pass 
the full path.

On Linux/Mac/*BSD, the extensions would be different: .obj -> .o, 
.lib -> .a. arsd.lib should be named libarsd.a. And the command 
line would look different as well:

dmd -I../../import foo.d -L-L../../lib -L-larsd

The -L switch is what you use to pass options to the linker. The 
first one, -L-L, gives the linker -L option, which on those 
systems tells the it append ../../lib to the library search path. 
The second one, -L-l (that's a lower-case 'L'), tells the linker 
to link with the library libarsd.a. You also need to link with 
any system dependencies the arsd modules have on those systems.
Oct 21 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 22 October 2016 at 01:31:25 UTC, Mike Parker wrote:

 * They can be passed directly to the compiler along with your 
 own source. This will cause them to be compiled and ultimately 
 linked into the resulting binary.



That's what I recommend. Just

dmd yourfile.d yourotherfiles.d color.d simpledisplay.d 
whatever_other_of_my_or_ketmars_files_you_use.d


That just works consistently.
Oct 21 2016
parent reply Jason C. Wells <example example.com> writes:
First, thank you for taking the time to help me with something 
that should be trivial.

I've done the above listing of file on the command line but I'm 
still stuck. I'm starting to think that I might actually be 
tripping over bugs, but I'm not confident enough to believe that 
without some confirmation.

I have the following directory structure from the zipfiles found 
in the repositories posted by ketmar.

nanovg_demo
- iv (was renamed from nanovg based on dmd error messages)
-- arsd (was renamed from arsd-master based on dmd error messages)

To proceed, I would attempt a compile. Then I would add the file 
that was producing an error to the command line and try again. I 
got this far.

Via cmd.exe:

   nanovg_demo>dmd example.d iv\arsd\color.d 
iv\arsd\simpledisplay.d iv\perf.d

   iv\perf.d(41): Error: module iv.nanovg.nanovg from file 
iv\nanovg.d must be
   imported with 'import iv.nanovg.nanovg;'

   demo.d(6): Error: module iv.nanovg.nanovg from file iv\nanovg.d 
must be
   imported with 'import iv.nanovg.nanovg;'

iv/nanovg/nanovg does not exist in the source code zip files. (I 
was reluctant to duplicate nanonvg into iv\nanovg because 
somewhere I learned that copy-pasting code is a bad idea.)

   demo.d(7): Error: module oui is in file 'iv\nanovg\oui.d' which 
cannot be read

oui.d does not exist anywhere. There is, however, a oui directory.

As a side note, I did have some success. I am able to compile 
nanovg.lib quite easily (from tips provided a few messages ago). 
It's when I try to compile the demo that I get stuck.

Regards,
Jason C. Wells
Oct 21 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells 
wrote:

 First, thank you for taking the time to help me with something 
 that should be trivial.

 I've done the above listing of file on the command line but I'm 
 still stuck. I'm starting to think that I might actually be 
 tripping over bugs, but I'm not confident enough to believe 
 that without some confirmation.


I think I can confidently assure you that you aren't running into 
any bugs here.


 I have the following directory structure from the zipfiles 
 found in the repositories posted by ketmar.

 nanovg_demo
 - iv (was renamed from nanovg based on dmd error messages)
 -- arsd (was renamed from arsd-master based on dmd error 
 messages)

 To proceed, I would attempt a compile. Then I would add the 
 file that was producing an error to the command line and try 
 again. I got this far.

 Via cmd.exe:

   nanovg_demo>dmd example.d iv\arsd\color.d 
 iv\arsd\simpledisplay.d iv\perf.d

   iv\perf.d(41): Error: module iv.nanovg.nanovg from file 
 iv\nanovg.d must be
   imported with 'import iv.nanovg.nanovg;'

   demo.d(6): Error: module iv.nanovg.nanovg from file 
 iv\nanovg.d must be
   imported with 'import iv.nanovg.nanovg;'

 iv/nanovg/nanovg does not exist in the source code zip files. 
 (I was reluctant to duplicate nanonvg into iv\nanovg because 
 somewhere I learned that copy-pasting code is a bad idea.)


looking at kemar's repository, the nanovg.d module belongs to the 
iv.nanovg package. I don't know what the zip directory tree looks 
like, but you should have this:

- iv
-- nanovg
--- fui
--- nanovg.d
--- oui
--- package.d
--- perf.d
--- svg.d

As for the asrd stuff, it shouldn't bee in the iv tree at all. 
You should do something like this:

- import
-- iv
-- arsd

Both iv and arsd are top-level packages, so they ought to be 
independent of each other.


   demo.d(7): Error: module oui is in file 'iv\nanovg\oui.d' 
 which cannot be read

 oui.d does not exist anywhere. There is, however, a oui 
 directory.


If you look at the source for demo.d, you'll see that it makes 
use of the oui package. That means the everything there also 
needs to be compiled and linked into the binary, but you haven't 
given those files to the compiler.



 As a side note, I did have some success. I am able to compile 
 nanovg.lib quite easily (from tips provided a few messages 
 ago). It's when I try to compile the demo that I get stuck.


Which files did you add into nanovg.lib? Everything in the 
iv.nanovg packages and subpackages, or just the ones you use 
directly? It's best to compile all of them into the lib, then any 
that are used indirectly by each other are also available.

You've dived right into a multi-module projects without a full 
understanding of imports and linking. I suggest you back up a bit 
and get familiar with the process before tackling ketmar and 
Adam's stuff. If they used dub, it would be a very easy process. 
Since they don't, and you have to manage it all manually, you 
need a solid understanding of how DMD handles this stuff and why 
you are getting the error messages you see.

Try playing around with simple single-function modules, starting 
with something like this:

io.d:
```
void print(string s)
{
    import std.stdio : writeln;
    writeln(s);
}
```

main.d:
```
import io;
void main() { print("Hello, D!"); }
```

Compile both:
dmd main.d io.d

Compile separately:
dmd -c io.d
dmd main.d io.obj


Move the io.d module into a package, mylib.io:

- main.d
-- mylib
--- io.d

Add a module statement to the top of io.d:
```
module mylib.io;
```

Change the import in main.d:

```
import mylib.io;
```

Try again compiling together, then separately. Then move the 
mylib directory:

- main.d
-- lib
--- mylib
---- io.d

Then compile together and separately again. Try with and without 
-Ilib in both cases and see what happens. Add another 
single-function module into the mix. Compile mylib as a library 
and try again.

Just keep experimenting like this until you've worked out exactly 
what's going on and what the error messages mean. Then you can 
tackle the naonvg and arsd.
Oct 21 2016
parent Jason C. Wells <example example.com> writes:
On Saturday, 22 October 2016 at 06:18:13 UTC, Mike Parker wrote:

 I think I can confidently assure you that you aren't running 
 into any bugs here.


Thanks for the confirmation. It helps me to learn.


 You've dived right into a multi-module projects without a full 
 understanding of imports and linking. I suggest you back up a 
 bit and get familiar with the process before tackling ketmar 
 and Adam's stuff. If they used dub, it would be a very easy 
 process. Since they don't, and you have to manage it all 
 manually, you need a solid understanding of how DMD handles 
 this stuff and why you are getting the error messages you see.


I'm used to compiling stuff in FreeBSD land. They have a group of 
people who take care to manage the build process (the dub part, i 
presume). What you say above is correct. I don't understand 
imports and linking. I can read the docs and they make sense, but 
I don't quite get it yet.

Thanks for writing up that simple exercise. That's next.

I was able to compile a working executable by specifying almost 
all *.d files on the command line. It didn't render an image, but 
it did pop up a window with an error message saying it couldn't 
load an image. I'm calling that victory.

Regards,
Jason
Oct 22 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells 
wrote:

   nanovg_demo>dmd example.d iv\arsd\color.d 
 iv\arsd\simpledisplay.d iv\perf.d

   iv\perf.d(41): Error: module iv.nanovg.nanovg from file 
 iv\nanovg.d must be
   imported with 'import iv.nanovg.nanovg;'

   demo.d(6): Error: module iv.nanovg.nanovg from file 
 iv\nanovg.d must be
   imported with 'import iv.nanovg.nanovg;'

 iv/nanovg/nanovg does not exist in the source code zip files. 
 (I was reluctant to duplicate nanonvg into iv\nanovg because 
 somewhere I learned that copy-pasting code is a bad idea.)


it's way easier, actually. first, you don't have to place files 
into correct directories if you are passing all of them (files) 
as arguments to dmd. they don't even have to have correct names. 
"correct" file placement is required only if dmd should search 
for modules on his own.

second: you simply didn't pass all the required modules. perf.d 
depends on core nanovg engine, but you didn't passed that to dmd.

the easiest way is just pall *all* *.d files you have to dmd. 
don't try to be picky ;-), dmd is fast enougth that you can 
safely pass alot of sources to it. and there is no harm in 
providing dmd with "extra" modules.


as for "correct" placement (if you want it), it should be like 
that:

dmd -Imodroot main.d
main.d is your main D file, modroot is dir where all modules will 
be. it should be like that:

modroot/arsd/color.d
modroot/arsd/<other Adam's modules here>
modroot/iv/nanovg/nanovg.d
modroot/iv/nanovg/<other NanoVG files here, keeping subdirs>


also, pref.d module is completely unnecessary, it is just utility 
thingy to show FPS counter. ;-)


p.s. you will also need stb_ttf port, arsd repo has it under the 
name "ttf.d".

p.p.s. the easiest way to do everything is this:
mkdir modroot
cd modroot
git clone git://repo.or.cz/iv.d.git iv
git clone https://github.com/adamdruppe/arsd.git arsd
cd ..
rdmd -Imodroot main.d

;-)
Oct 22 2016
parent Jason C. Wells <example example.com> writes:
Now I think I finally see where my hang up is.

If B imports C, and A imports B and C, you still have to tell A 
where to find C. C doesn't go along for the ride with B. Stated 
another way, A doesn't look inside B to find C. Stated yet 
another way, B does not expose C to A.

The statement above that I did not include nanovg.d on the 
command line finally clued me in. The statement that I was being 
"picky" about what to compile similarly helped.

sh$> dmd $(find . -name "*.d") <== a joke, sort of.

Eager to make the next try. Gotta run for a bit.
Oct 22 2016
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 19 October 2016 at 03:27:10 UTC, Basile B. wrote:

 https://github.com/Pctg-x8/nanovg-d, I even think it's been 
 announced here last year.


this is wrapper. my thing is complete port.
Oct 19 2016
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tuesday, 18 October 2016 at 21:00:12 UTC, Karabuta wrote:

 This thing really needs a GitHub repo


never.
Oct 19 2016