www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - I've just released Vasaro

reply Andrea Fontana <nospam example.com> writes:
Hi!

I've just released the first version of vasaro.
It's a simple program I wrote to create 3d printable vases.

It's written in D (of course). It uses derelict-gl, derelict-sdl 
and gtkd.

It should work on linux, macOS and Windows.

A special thanks to Adam Ruppe and his SimpleDisplay library I 
used on earlier versions :)

A demo video:
https://www.youtube.com/watch?v=HkYo8WCW9jM

On reddit: 
https://www.reddit.com/r/3Dprinting/comments/a3qykj/ive_just_released_vasaro_the_easytouse_software/

On github:
https://github.com/trikko/vasaro/


Feel free to test it!

Andrea
Dec 06 2018
next sibling parent reply kinke <noone nowhere.com> writes:
On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
wrote:

 [...]


Pretty cool, thx for sharing! I watched the demo and had an 
extremely superficial glance at the code too; seems to make D 
look good, as it deserves, so thanks for that as well. :)
Dec 06 2018
parent Andrea Fontana <nospam example.com> writes:
On Thursday, 6 December 2018 at 21:03:49 UTC, kinke wrote:

 On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
 wrote:

 [...]


 Pretty cool, thx for sharing! I watched the demo and had an 
 extremely superficial glance at the code too; seems to make D 
 look good, as it deserves, so thanks for that as well. :)


Thank you!

I forgot to ask you all to upvote on reddit ;)

Andrea
Dec 06 2018
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
wrote:

 A special thanks to Adam Ruppe and his SimpleDisplay library I 
 used on earlier versions :)


why you go gtk in the end?
Dec 06 2018
parent reply Andrea Fontana <nospam example.com> writes:
On Friday, 7 December 2018 at 01:17:02 UTC, Adam D. Ruppe wrote:

 On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
 wrote:

 A special thanks to Adam Ruppe and his SimpleDisplay library I 
 used on earlier versions :)


 why you go gtk in the end?


I replaced simpledisplay with sdl. Gtk doesn't support opengl2 so 
I needed a way to display the rendering window.

Simpledisplay works fine for me (and it works better than sdl for 
mouse input) but it requires X11 on macOS if i'm right: macOS' 
users don't like X11 (and this force users to install a big 
dependency)

If it was only for linux+win, simpledisplay would be the choice!

Andrea
Dec 07 2018
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 7 December 2018 at 08:05:47 UTC, Andrea Fontana wrote:

 Simpledisplay works fine for me (and it works better than sdl 
 for mouse input) but it requires X11 on macOS if i'm right: 
 macOS' users don't like X11 (and this force users to install a 
 big dependency)


Ah yes, I sometimes get tempted to add Cocoa support, but (aside 
from one user contribution around 2012ish) I never get further 
than hello world. I do now have a mac... but I hate it, so I have 
no particular personal drive to make stuff work there.

But who knows, maybe eventually I'll get the code going there. 
Indeed though, not right now.
Dec 07 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-12-07 at 20:47 +0000, Adam D. Ruppe via Digitalmars-d-announce
wrote:

=20


[=E2=80=A6]

 Ah yes, I sometimes get tempted to add Cocoa support, but (aside=20
 from one user contribution around 2012ish) I never get further=20
 than hello world. I do now have a mac... but I hate it, so I have=20
 no particular personal drive to make stuff work there.
=20
 But who knows, maybe eventually I'll get the code going there.=20
 Indeed though, not right now.


If you don't want the macOS laptop and it is a post-2014 one, I'd be
interested. The MacBook Pro I have will only run El Capitan and Homebrew ha=
s
stopped supporting it with bottles, so it is now useless for development wo=
rk
=E2=80=93 or in my case testing that stuff developed on Debian actually als=
o works on
macOS.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Dec 08 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 8 December 2018 at 08:30:08 UTC, Russel Winder wrote:

 If you don't want the macOS laptop and it is a post-2014 one, 
 I'd be interested.


The one I have is a macbook air with a broken, but usable screen 
(I got it for free yay). I don't know how old it is, I *think* it 
is a 2013 model. I know it won't take the new OS update from 
Apple, but it was able to run dmd on it last time I tried (which 
was like 9 months ago lol).

As long as dmd runs, it is potentially useful to me, just while I 
know XLib and Win32 already, I know basically nothing about obj-c 
and cocoa, and I'm not terribly motivated since I can't stand Mac 
OS as an end user either, so I don't see myself ever actually 
using this stuff.

Still, it is a feature request from time to time, and I imagine 
basic 2d drawing and input events aren't likely to change *that* 
much, so if I can get it working on this old computer I figure 
the library will probably also work on newer ones - or at least 
it will be easy for a OSX developer to send me a bugfix PR.
Dec 08 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-08 18:01, Adam D. Ruppe wrote:


 The one I have is a macbook air with a broken, but usable screen (I got 
 it for free yay). I don't know how old it is, I *think* it is a 2013 
 model.


If you click on the Apple menu in the top left corner and choose "About 
This Mac", it will say which model and which year in the window that 
appears. It will also specify which version of the OS it's running.


 I know it won't take the new OS update from Apple, but it was 
 able to run dmd on it last time I tried (which was like 9 months ago lol).


DMD will run on Mavericks (10.9) or later.

If you don't want to keep it you could always donate it as a testing 
machine, if the Dlang foundation will accept it.

-- 
/Jacob Carlborg
Dec 10 2018
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 10 December 2018 at 10:47:42 UTC, Jacob Carlborg wrote:

 On 2018-12-08 18:01, Adam D. Ruppe wrote:


 The one I have is a macbook air with a broken, but usable 
 screen (I got it for free yay). I don't know how old it is, I 
 *think* it is a 2013 model.


 If you click on the Apple menu in the top left corner and 
 choose "About This Mac", it will say which model and which year 
 in the window that appears. It will also specify which version 
 of the OS it's running.


 I know it won't take the new OS update from Apple, but it was 
 able to run dmd on it last time I tried (which was like 9 
 months ago lol).


 DMD will run on Mavericks (10.9) or later.


I have a 10.6 that I will be re-adding port of druntime/phobos to 
(2.076 and later), and I think gcc also has a 10.4 in their 
server farm.

Anything that I find is missing that belongs in common parts I'll 
raise a pull to re-add, as it costs us nothing to support it.

Is there any consideration apart from section/tls support?  I'm 
just going to fork the current rt.sections stuff (I.e: 
gcc.sections.{elf,macho,pef,x off}) as apart from linux/elf, the 
rest is not of any use or is specific to dmd object format.  As 
for tls, well there is still no native support in gcc if I 
understand correctly.
Dec 10 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-10 12:26, Iain Buclaw wrote:


 Is there any consideration apart from section/tls support? 


There's the backtrace implementation for exceptions as well, 
"rt.backtrace". I had to slight modify the DMD backend to get that to 
work the same as it does on Linux and FreeBSD. I've documented how it's 
implemented in the commit message [1].


 I'm just going to fork the current rt.sections stuff (I.e: 
 gcc.sections.{elf,macho,pef,x off}) as apart from linux/elf, the rest is 
 not of any use or is specific to dmd object format. 


You should be able to reuse most parts of rt.sections_osx_x86. I don't 
think there's anything in that file that won't work on x86-64. But you 
would need to adjust it for the TLS implementation you're using.


 As for tls, well  there is still no native support in gcc if I understand
correctly.


It was pretty straight forward (once I figured it out :) ) to implement 
in DMD and it's pretty well documented you want to implement it in GCC.

[1] 
https://github.com/dlang/dmd/commit/2bf7d0db29416eacbb01a91e6502140e354ee0ef

-- 
/Jacob Carlborg
Dec 11 2018
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tuesday, 11 December 2018 at 10:30:54 UTC, Jacob Carlborg 
wrote:

 On 2018-12-10 12:26, Iain Buclaw wrote:


 Is there any consideration apart from section/tls support?


 There's the backtrace implementation for exceptions as well, 
 "rt.backtrace". I had to slight modify the DMD backend to get 
 that to work the same as it does on Linux and FreeBSD. I've 
 documented how it's implemented in the commit message [1].


We're covered by libbacktrace, rather than tthe druntime 
implementation.

https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README


 I'm just going to fork the current rt.sections stuff (I.e: 
 gcc.sections.{elf,macho,pef,x off}) as apart from linux/elf, 
 the rest is not of any use or is specific to dmd object format.


 You should be able to reuse most parts of rt.sections_osx_x86. 
 I don't think there's anything in that file that won't work on 
 x86-64. But you would need to adjust it for the TLS 
 implementation you're using.


Unlike dmd, we don't really have full control over how things end 
up in the object.  There are a couple coaxing methods used which 
allowed us to use elf_shared without modification.  Other object 
formats I don't think we'll be so lucky over.

I'll try really hard though to keep the same implementation used 
for elf in others however - just different section names 
depending on what is accepted by the assembler.


 As for tls, well  there is still no native support in gcc if I 
 understand correctly.


 It was pretty straight forward (once I figured it out :) ) to 
 implement in DMD and it's pretty well documented you want to 
 implement it in GCC.


I'll leave that to the binutils people.  Supporting emutls also 
means we'll work on mingw too, which has a similar say story 
regarding state of native tls.

Besides, it will only work for newer OSX releases, not ~10.5 
which is roughly the base version aimed to support.
Dec 11 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-11 12:13, Iain Buclaw wrote:


 We're covered by libbacktrace, rather than tthe druntime implementation.
 
 https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README


Looks like Mach-O is not supported. It looks like it uses DWARF, but I 
don't know how you plan to have that working when the executable doesn't 
contain any DWARF data ;).


 Besides, it will only work for newer OSX releases, not ~10.5 which is 
 roughly the base version aimed to support.


I still don't see any point in supporting these old version that Apple 
has dropped support for since many years ago.

-- 
/Jacob Carlborg
Dec 11 2018
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tuesday, 11 December 2018 at 11:24:37 UTC, Jacob Carlborg 
wrote:

 On 2018-12-11 12:13, Iain Buclaw wrote:


 We're covered by libbacktrace, rather than tthe druntime 
 implementation.
 
 https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README


 Looks like Mach-O is not supported. It looks like it uses 
 DWARF, but I don't know how you plan to have that working when 
 the executable doesn't contain any DWARF data ;).


 Besides, it will only work for newer OSX releases, not ~10.5 
 which is roughly the base version aimed to support.


 I still don't see any point in supporting these old version 
 that Apple has dropped support for since many years ago.


Dwarf data is emitted on OSX. The section where to find all debug 
symbols is prefixed by "__DWARF".  Even DMD does this on OSX. ;-)

https://github.com/dlang/dmd/blob/dff0138467ec451ac64e1dac392a1a9648ee2523/src/dmd/backend/dwarfdbginf.d#L150-L151
Dec 11 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-11 13:23, Iain Buclaw wrote:


 Dwarf data is emitted on OSX. The section where to find all debug
 symbols is prefixed by "__DWARF".  Even DMD does this on OSX. ;-)


Yes, but the linker strips any sections with the "S_ATTR_DEBUG" flag, 
which includes the everything in the "__DWARF" segment. Here's my commit 
message for convenience:

The linker on macOS will remove any debug info, i.e. every section
with the `S_ATTR_DEBUG` flag, this includes everything in the
`__DWARF` section. By using the `S_REGULAR` flag the linker will not
remove this section. This allows to get the filenames and line numbers
for backtraces from the executable.

Normally the linker removes all the debug info but adds a reference to
the object files. The debugger can then read the object files to get
filename and line number information. It's also possible to use an
additional tool that generates a separate `.dSYM` file. This file can
then later be deployed with the application if debug info is needed
when the application is deployed.

-- 
/Jacob Carlborg
Dec 11 2018
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tuesday, 11 December 2018 at 16:32:31 UTC, Jacob Carlborg 
wrote:

 On 2018-12-11 13:23, Iain Buclaw wrote:


 Dwarf data is emitted on OSX. The section where to find all 
 debug
 symbols is prefixed by "__DWARF".  Even DMD does this on OSX. 
 ;-)


 Yes, but the linker strips any sections with the "S_ATTR_DEBUG" 
 flag, which includes the everything in the "__DWARF" segment. 
 Here's my commit message for convenience:

 The linker on macOS will remove any debug info, i.e. every 
 section
 with the `S_ATTR_DEBUG` flag, this includes everything in the
 `__DWARF` section. By using the `S_REGULAR` flag the linker 
 will not
 remove this section. This allows to get the filenames and line 
 numbers
 for backtraces from the executable.

 Normally the linker removes all the debug info but adds a 
 reference to
 the object files. The debugger can then read the object files 
 to get
 filename and line number information. It's also possible to use 
 an
 additional tool that generates a separate `.dSYM` file. This 
 file can
 then later be deployed with the application if debug info is 
 needed
 when the application is deployed.


Well, as a front-end language dev, how gcc emits things is not my 
bailiwick, just so long as I can guarantee language semantics. :-)
Dec 11 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 10 December 2018 at 10:47:42 UTC, Jacob Carlborg wrote:

 If you click on the Apple menu in the top left corner and 
 choose "About This Mac", it will say which model and which year 
 in the window that appears. It will also specify which version 
 of the OS it's running.


Ah, there it is: 10.9.5, 1.6 GhZ Core i5, 2 GB. (c) 2016. 
Actually not that old.


 If you don't want to keep it you could always donate it as a 
 testing machine, if the Dlang foundation will accept it.


Well, I still want to add the support to my library anyway. At 
least the minimal stuff - create window, create opengl context, 
dispatch events, so it can serve as a base for other users to PR 
the other functions if they use it. I am also very slowly working 
on some objc helper functions (though I wish the headers were at 
least in druntime like win32 is now)

That's why I got this and it is still on my list, it is just 
somewhat far down on my list.
Dec 10 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-10 14:55, Adam D. Ruppe wrote:


 Ah, there it is: 10.9.5, 1.6 GhZ Core i5, 2 GB. (c) 2016. Actually not 
 that old.


Which year is the machine from? It should say that after the model. For 
me it says: "MacBook (Retina, 12-inch, Early 2015)". If it's from mid 
2012 or newer you can upgrade to the latest version of macOS, if you 
want to [1].


 Well, I still want to add the support to my library anyway. At least the 
 minimal stuff - create window, create opengl context, dispatch events, 
 so it can serve as a base for other users to PR the other functions if 
 they use it. I am also very slowly working on some objc helper functions 
 (though I wish the headers were at least in druntime like win32 is now)
 
 That's why I got this and it is still on my list, it is just somewhat 
 far down on my list.


I would recommend waiting until more of the Objective-C support is 
implemented. Creating a subclass is a pain in the ass currently.

[1] https://support.apple.com/kb/SP777?locale=en_US

-- 
/Jacob Carlborg
Dec 11 2018
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg 
wrote:

 Which year is the machine from? It should say that after the 
 model.


Oh, I had to click "more info".

MacBook Air
11-inch, Mid 2011

So I guess it is quite old. I have tried to do the OS update 
several times before and it consistently just freezes (usually 
the progress bar stops, the system keeps working, but one time it 
did outright restart itself), this probably explains why.


 I would recommend waiting until more of the Objective-C support 
 is implemented. Creating a subclass is a pain in the ass 
 currently.


Yeah, I know. I have made some mixins to help smooth it over a 
little though. That is one of the reasons why I am waiting a bit, 
but I feel if I wait on dmd I'll be waiting forever. I'd like at 
least the basics to work.
Dec 12 2018
parent Jacob Carlborg <doob me.com> writes:
On 2018-12-12 15:52, Adam D. Ruppe wrote:

 On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg wrote:

 Which year is the machine from? It should say that after the model.


 Oh, I had to click "more info".

 MacBook Air
 11-inch, Mid 2011

 So I guess it is quite old. I have tried to do the OS update several
 times before and it consistently just freezes (usually the progress bar
 stops, the system keeps working, but one time it did outright restart
 itself), this probably explains why.



Yes, it's too old for Mojave. But it looks like you can run High Sierra 
[1]. It's just one version old.

[1] https://support.apple.com/kb/SP765?locale=en_US

-- 
/Jacob Carlborg
Dec 13 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg 
wrote:

 I would recommend waiting until more of the Objective-C support 
 is implemented. Creating a subclass is a pain in the ass 
 currently.


So I got out my code that (with your help about a year ago) was 
doing a hello world window and menu, but now it doesn't compile, 
complaining about a hidden Class clashing with my Class.

What is the current state and roadmap for this support? The stuff 
described here seems wrong: 
https://dlang.org/spec/objc_interface.html and this apparently 
hasn't been edited for years: https://wiki.dlang.org/DIP43 but 
SEEMS to be what closest matches up.
Dec 12 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-13 00:36, Adam D. Ruppe wrote:


 So I got out my code that (with your help about a year ago) was doing a
 hello world window and menu, but now it doesn't compile, complaining
 about a hidden Class clashing with my Class.


Hmm, it was not my intention for that to be exposed yet.

You don't need that hack with an extra interface called "Class" anymore. 
It's now possible to declare static/class methods directly, which wasn't 
possible before.

Technically in Objective-C static methods are instance methods on the 
metaclass. All classes in Objective-C are objects, they're instance of 
the metaclass. Each class has a corresponding metaclass. The 
class/interface you have implemented called "Class" was the metaclass, 
manually declared. This metaclass is normally not visible in the source 
code in Objective-C. What we did was we declared instance methods on the 
metaclass, this is now handled behind the scenes when you're declaring a 
method with "static" in the normal class/interface.

If you're code is looking like this:

extern (Objective-C) interface Foo
{
     extern (Objective-C) interface Class
     {
         Foo alloc()  selector("alloc");
     }
}

You can now replace it with this code:

extern (Objective-C) interface Foo
{
     static Foo alloc()  selector("alloc");
}

And you can directly call "Foo.alloc()".

It was not my intention to break existing code. I think if you rename 
your "Class" to something else it will continue to work.


 What is the current state and roadmap for this support?


There's no roadmap. It's whenever I got time to work on the Objective-C 
integration. Lately I've been prioritizing other work. But it would be 
the next thing on the list of Objective-C features to implement.


 The stuff described here seems wrong:
https://dlang.org/spec/objc_interface.html


No, that's correct. The example at the bottom compiles and runs 
correctly using DMD 2.083.0.


 and this apparently hasn't been edited for years:
 https://wiki.dlang.org/DIP43 but SEEMS to be what closest matches up.


I'm not sure if DIP43 needs to be changed. It's what I'm following when 
implementing, more or less. It's just that not everything in DIP43 has 
been implemented yet.

-- 
/Jacob Carlborg
Dec 13 2018
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 13 December 2018 at 21:55:00 UTC, Jacob Carlborg 
wrote:

 You don't need that hack with an extra interface called "Class" 
 anymore. It's now possible to declare static/class methods 
 directly, which wasn't possible before.


Oh, nice. Yeah, that's what it was. I renamed it and got it to 
compile and run again, but it really is a bunch of ugliness so 
being able to remove it is nice.

I am still having some trouble with the child classes, but you 
said that still sucks. My mixins basically do it, but yeah I am 
looking forward to this just working.



 I'm not sure if DIP43 needs to be changed. It's what I'm 
 following when implementing, more or less. It's just that not 
 everything in DIP43 has been implemented yet.


I see. Well, thanks for your work on this. It is coming together 
nicely.
Dec 13 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-12-07 09:05, Andrea Fontana wrote:


 Simpledisplay works fine for me (and it works better than sdl for mouse 
 input) but it requires X11 on macOS if i'm right: macOS' users don't 
 like X11 (and this force users to install a big dependency)


Yes, X11 is definitively not acceptable on macOS.

-- 
/Jacob Carlborg
Dec 08 2018
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
wrote:

 Hi!

 I've just released the first version of vasaro.
 It's a simple program I wrote to create 3d printable vases.

 It's written in D (of course). It uses derelict-gl, 
 derelict-sdl and gtkd.


Looks nice. I'll give it a go when I plug my 3d printer.

Why use derelict-sdl if you use gtkd already?
Dec 06 2018
next sibling parent Andrea Fontana <nospam example.com> writes:
On Friday, 7 December 2018 at 07:22:18 UTC, JN wrote:

 Looks nice. I'll give it a go when I plug my 3d printer.


Waiting for your feedback.


 Why use derelict-sdl if you use gtkd already?


Good question. Gtk doesn't support opengl2.
Why do I use OpenGL2?
- I don't know ogl3
- I just need basic 3d features
- It works everywhere (also on VM I use to test it)

Andrea
Dec 06 2018
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 7 December 2018 at 07:22:18 UTC, JN wrote:

 Looks nice. I'll give it a go when I plug my 3d printer.


Make sure it prints watertight before using the vase for fresh 
flowers :-)
Dec 07 2018
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
wrote:

 Hi!

 I've just released the first version of vasaro.
 It's a simple program I wrote to create 3d printable vases.

 It's written in D (of course). It uses derelict-gl, 
 derelict-sdl and gtkd.

 It should work on linux, macOS and Windows.

 A special thanks to Adam Ruppe and his SimpleDisplay library I 
 used on earlier versions :)

 A demo video:
 https://www.youtube.com/watch?v=HkYo8WCW9jM

 On reddit: 
 https://www.reddit.com/r/3Dprinting/comments/a3qykj/ive_just_released_vasaro_the_easytouse_software/

 On github:
 https://github.com/trikko/vasaro/


 Feel free to test it!

 Andrea


This is a very impressive project and I'll follow it just to see 
where it goes.

I have zero to no experience with 3d printing so I can't really 
relate much to it.
Dec 07 2018
parent Andrea Fontana <nospam example.com> writes:
On Friday, 7 December 2018 at 13:32:10 UTC, bauss wrote:

 This is a very impressive project and I'll follow it just to 
 see where it goes.

 I have zero to no experience with 3d printing so I can't really 
 relate much to it.


Thank you!

If you eventually start with 3d printing you'll notice that there 
are a lot of vases  to print. People loves them (for many 
reasons). However it's not that easy to model a nice (artistic) 
vase: it requires a good knowledge of 3d editors and also if you 
have some pratice with them, you can have a hard time to make 
models printable.

Vasaro let you create nice vases in just a few minutes and it 
makes a lot of users happy. :)
Dec 07 2018
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana 
wrote:

 Hi!

 I've just released the first version of vasaro.
 It's a simple program I wrote to create 3d printable vases.

 It's written in D (of course). It uses derelict-gl, 
 derelict-sdl and gtkd.

 It should work on linux, macOS and Windows.

 A special thanks to Adam Ruppe and his SimpleDisplay library I 
 used on earlier versions :)

 A demo video:
 https://www.youtube.com/watch?v=HkYo8WCW9jM

 On reddit: 
 https://www.reddit.com/r/3Dprinting/comments/a3qykj/ive_just_released_vasaro_the_easytouse_software/

 On github:
 https://github.com/trikko/vasaro/


 Feel free to test it!

 Andrea


Nice, when does the version with genetic algorithms come out? ;)

https://www.economist.com/technology-quarterly/2015/09/03/wonderful-widgets

JK, of course, demo looks good.
Dec 07 2018
parent Andrea Fontana <nospam example.com> writes:
On Friday, 7 December 2018 at 15:03:38 UTC, Joakim wrote:

 Nice, when does the version with genetic algorithms come out? ;)

 https://www.economist.com/technology-quarterly/2015/09/03/wonderful-widgets

 JK, of course, demo looks good.


Trust me or not, this is a planned feature.

Andrea
Dec 07 2018