I
irevdev
Sun, Mar 21, 2021 7:17 PM
Wow, a lot of interesting things going on with makertron.
I've been trying to keep it simple, mostly for my own sake. Which is why I'm
just running stock OpenSCAD on the server.
--
Sent from: http://forum.openscad.org/
Wow, a lot of interesting things going on with makertron.
I've been trying to keep it simple, mostly for my own sake. Which is why I'm
just running stock OpenSCAD on the server.
--
Sent from: http://forum.openscad.org/
DT
Damien Towning
Sun, Mar 21, 2021 7:55 PM
I did that first to. Somewhere in my revisions is a headless copy of the
OpenScad that sat on a socket. But then you get in to the performance
penalties of the geometry transfer and problems with parallelisation. When
I weighed up trying to bring the OpenSCAD headless in to the multi parallel
I decided just to start my own implementation. As a lot of people have
reiterated just leave the poor OpenSCAD alone. It is fine to be compatible
or mostly compatible. The problem to be solved isn't the OpenSCAD !
Somebody will mention mowing the lawns at that point. Anyway if you go this
way with making the OpenSCAD headless ( and it isn't in my opinion now the
right way to go ) the bit to get 'out' and on the client is the Gold
Feather. As I contemplated that I decided a clean way was to probably
implement it by building a c++ module of it through the web assembly rather
than trying to implement it in the JavaScript. What else. My first headless
version using the OpenSCAD also used node and I had a whole effort to do my
parallelisation in that. Terrible idea. Just not the right tools for the
job. I hope what I have learned can help others to short cut to the actual
problems that need to be solved.
On Mon, Mar 22, 2021 at 6:17 AM irevdev via Discuss <
discuss@lists.openscad.org> wrote:
Wow, a lot of interesting things going on with makertron.
I've been trying to keep it simple, mostly for my own sake. Which is why
I'm just running stock OpenSCAD on the server.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I did that first to. Somewhere in my revisions is a headless copy of the
OpenScad that sat on a socket. But then you get in to the performance
penalties of the geometry transfer and problems with parallelisation. When
I weighed up trying to bring the OpenSCAD headless in to the multi parallel
I decided just to start my own implementation. As a lot of people have
reiterated just leave the poor OpenSCAD alone. It is fine to be compatible
or mostly compatible. The problem to be solved isn't the OpenSCAD !
Somebody will mention mowing the lawns at that point. Anyway if you go this
way with making the OpenSCAD headless ( and it isn't in my opinion now the
right way to go ) the bit to get 'out' and on the client is the Gold
Feather. As I contemplated that I decided a clean way was to probably
implement it by building a c++ module of it through the web assembly rather
than trying to implement it in the JavaScript. What else. My first headless
version using the OpenSCAD also used node and I had a whole effort to do my
parallelisation in that. Terrible idea. Just not the right tools for the
job. I hope what I have learned can help others to short cut to the actual
problems that need to be solved.
On Mon, Mar 22, 2021 at 6:17 AM irevdev via Discuss <
discuss@lists.openscad.org> wrote:
> Wow, a lot of interesting things going on with makertron.
>
> I've been trying to keep it simple, mostly for my own sake. Which is why
> I'm just running stock OpenSCAD on the server.
> ------------------------------
> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
> at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
--
Damien Towning
DT
Damien Towning
Sun, Mar 21, 2021 8:00 PM
Or to follow this up a bit more ... a clean way is rather than having the
whole of OpenSCAD sitting on the server through something horrid like node
and the FFL or whatever it was called ( some dreadful c binding through the
garbage that is node ) .... build the core bits of OpenSCAD minus the
rendering / OpenGL .... in web assembly ... for a start you get the
interface and the editor ... all of which are well polished and decent
.... several years of reading the code .... leaves me with the opinion
that lots of the code base is really quite beautiful .. but it also has to
depend on other things of course ... which are not so beautiful ... more
opions .. CGAL is f'ing ugly ...
On Mon, Mar 22, 2021 at 6:55 AM Damien Towning connolly.damien@gmail.com
wrote:
I did that first to. Somewhere in my revisions is a headless copy of the
OpenScad that sat on a socket. But then you get in to the performance
penalties of the geometry transfer and problems with parallelisation. When
I weighed up trying to bring the OpenSCAD headless in to the multi parallel
I decided just to start my own implementation. As a lot of people have
reiterated just leave the poor OpenSCAD alone. It is fine to be compatible
or mostly compatible. The problem to be solved isn't the OpenSCAD !
Somebody will mention mowing the lawns at that point. Anyway if you go this
way with making the OpenSCAD headless ( and it isn't in my opinion now the
right way to go ) the bit to get 'out' and on the client is the Gold
Feather. As I contemplated that I decided a clean way was to probably
implement it by building a c++ module of it through the web assembly rather
than trying to implement it in the JavaScript. What else. My first headless
version using the OpenSCAD also used node and I had a whole effort to do my
parallelisation in that. Terrible idea. Just not the right tools for the
job. I hope what I have learned can help others to short cut to the actual
problems that need to be solved.
On Mon, Mar 22, 2021 at 6:17 AM irevdev via Discuss <
discuss@lists.openscad.org> wrote:
Wow, a lot of interesting things going on with makertron.
I've been trying to keep it simple, mostly for my own sake. Which is why
I'm just running stock OpenSCAD on the server.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Or to follow this up a bit more ... a clean way is rather than having the
whole of OpenSCAD sitting on the server through something horrid like node
and the FFL or whatever it was called ( some dreadful c binding through the
garbage that is node ) .... build the core bits of OpenSCAD minus the
rendering / OpenGL .... in web assembly ... for a start you get the
interface and the editor ... all of which are well polished and decent
.... several years of reading the code .... leaves me with the opinion
that lots of the code base is really quite beautiful .. but it also has to
depend on other things of course ... which are not so beautiful ... more
opions .. CGAL is f'ing ugly ...
On Mon, Mar 22, 2021 at 6:55 AM Damien Towning <connolly.damien@gmail.com>
wrote:
> I did that first to. Somewhere in my revisions is a headless copy of the
> OpenScad that sat on a socket. But then you get in to the performance
> penalties of the geometry transfer and problems with parallelisation. When
> I weighed up trying to bring the OpenSCAD headless in to the multi parallel
> I decided just to start my own implementation. As a lot of people have
> reiterated just leave the poor OpenSCAD alone. It is fine to be compatible
> or mostly compatible. The problem to be solved isn't the OpenSCAD !
> Somebody will mention mowing the lawns at that point. Anyway if you go this
> way with making the OpenSCAD headless ( and it isn't in my opinion now the
> right way to go ) the bit to get 'out' and on the client is the Gold
> Feather. As I contemplated that I decided a clean way was to probably
> implement it by building a c++ module of it through the web assembly rather
> than trying to implement it in the JavaScript. What else. My first headless
> version using the OpenSCAD also used node and I had a whole effort to do my
> parallelisation in that. Terrible idea. Just not the right tools for the
> job. I hope what I have learned can help others to short cut to the actual
> problems that need to be solved.
>
> On Mon, Mar 22, 2021 at 6:17 AM irevdev via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> Wow, a lot of interesting things going on with makertron.
>>
>> I've been trying to keep it simple, mostly for my own sake. Which is why
>> I'm just running stock OpenSCAD on the server.
>> ------------------------------
>> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
>> at Nabble.com.
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
>
> --
> Damien Towning
>
>
>
--
Damien Towning
I
irevdev
Sun, Mar 21, 2021 11:15 PM
@mixotricha, I not sure understand, do you think there's a problem with my
solution?
I don't have a geometry transfer problem because I'm not transferring
geometry only images (which has it's own disadvantages, but one I'm willing
to wear). And I don't a parallel problem as I'm just letting AWS handle that
as it's deployed as a lambda.
--
Sent from: http://forum.openscad.org/
@mixotricha, I not sure understand, do you think there's a problem with my
solution?
I don't have a geometry transfer problem because I'm not transferring
geometry only images (which has it's own disadvantages, but one I'm willing
to wear). And I don't a parallel problem as I'm just letting AWS handle that
as it's deployed as a lambda.
--
Sent from: http://forum.openscad.org/
DT
Damien Towning
Mon, Mar 22, 2021 12:19 AM
Depends on the design goal. I am working on a distributed high speed
OpenSCAD 'parser' for handling large geometrical problems on a distributed
cluster. This is for large complicated objects. Things like industrial
plumbing layouts. Streaming an instance of OpenSCAD to a web interface
would be my worst choice for solving that problem. Is not a problem for a
small fiddle though to tinker with at small scale. Sooner or later you have
to scale this on the AWS. Then you learn about the costs. At some point I
built a distributed cluster on the AWS using the star stuff. Each node held
a headless OpenSCAD. It ate resources like a swarm of hungry mice. This was
when I began to ponder metal. I've actually actually built my own dedicated
cluster with custom FPGA in it and such like to manage my costs and cut out
fat. I don't want to discourage anybody from going here though. Just trying
to relay what I have learned. This is work is important. You will also find
it generalises to a lot of useful other problems. If you think you can
solve the app on one end and stream it directly to the client on the other
end problem at scale at some reasonable cost. Then that is great! When I
looked at this it was my worst possible design choice to implement. However
as stated what you can do is to reshape the asymmetry you currently have by
moving the Gold Feather to the client. If people understand what I am
saying and think that would be a useful addition to have via the three.js I
might bump it up my project list. But beyond all this are better more
significant problems to solve first. The Gold Feather is done. It doesn't
need to be invented. It just needs to be moved. Anybody could do that.
Is beautiful paper. If have not read it. Reads it. From my former
university indeed it is.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.6932&rep=rep1&type=pdf
I will try and pull my paper together to. LaTex. Just got lots to do.
On Mon, Mar 22, 2021 at 10:15 AM irevdev via Discuss <
discuss@lists.openscad.org> wrote:
@mixotricha, I not sure understand, do you think there's a problem with my
solution?
I don't have a geometry transfer problem because I'm not transferring
geometry only images (which has it's own disadvantages, but one I'm willing
to wear). And I don't a parallel problem as I'm just letting AWS handle
that as it's deployed as a lambda.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Depends on the design goal. I am working on a distributed high speed
OpenSCAD 'parser' for handling large geometrical problems on a distributed
cluster. This is for large complicated objects. Things like industrial
plumbing layouts. Streaming an instance of OpenSCAD to a web interface
would be my worst choice for solving that problem. Is not a problem for a
small fiddle though to tinker with at small scale. Sooner or later you have
to scale this on the AWS. Then you learn about the costs. At some point I
built a distributed cluster on the AWS using the star stuff. Each node held
a headless OpenSCAD. It ate resources like a swarm of hungry mice. This was
when I began to ponder metal. I've actually actually built my own dedicated
cluster with custom FPGA in it and such like to manage my costs and cut out
fat. I don't want to discourage anybody from going here though. Just trying
to relay what I have learned. This is work is important. You will also find
it generalises to a lot of useful other problems. If you think you can
solve the app on one end and stream it directly to the client on the other
end problem at scale at some reasonable cost. Then that is great! When I
looked at this it was my worst possible design choice to implement. However
as stated what you can do is to reshape the asymmetry you currently have by
moving the Gold Feather to the client. If people understand what I am
saying and think that would be a useful addition to have via the three.js I
might bump it up my project list. But beyond all this are better more
significant problems to solve first. The Gold Feather is done. It doesn't
need to be invented. It just needs to be moved. Anybody could do that.
Is beautiful paper. If have not read it. Reads it. From my former
university indeed it is.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.6932&rep=rep1&type=pdf
I will try and pull my paper together to. LaTex. Just got lots to do.
On Mon, Mar 22, 2021 at 10:15 AM irevdev via Discuss <
discuss@lists.openscad.org> wrote:
> @mixotricha, I not sure understand, do you think there's a problem with my
> solution?
>
> I don't have a geometry transfer problem because I'm not transferring
> geometry only images (which has it's own disadvantages, but one I'm willing
> to wear). And I don't a parallel problem as I'm just letting AWS handle
> that as it's deployed as a lambda.
> ------------------------------
> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
> at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
--
Damien Towning
DT
Damien Towning
Mon, Mar 22, 2021 12:42 AM
Depends on the design goal. I am working on a distributed high speed
OpenSCAD 'parser' for handling large geometrical problems on a distributed
cluster. This is for large complicated objects. Things like industrial
plumbing layouts. Streaming an instance of OpenSCAD to a web interface
would be my worst choice for solving that problem. Is not a problem for a
small fiddle though to tinker with at small scale. Sooner or later you have
to scale this on the AWS. Then you learn about the costs. At some point I
built a distributed cluster on the AWS using the star stuff. Each node held
a headless OpenSCAD. It ate resources like a swarm of hungry mice. This was
when I began to ponder metal. I've actually actually built my own dedicated
cluster with custom FPGA in it and such like to manage my costs and cut out
fat. I don't want to discourage anybody from going here though. Just trying
to relay what I have learned. This is work is important. You will also find
it generalises to a lot of useful other problems. If you think you can
solve the app on one end and stream it directly to the client on the other
end problem at scale at some reasonable cost. Then that is great! When I
looked at this it was my worst possible design choice to implement. However
as stated what you can do is to reshape the asymmetry you currently have by
moving the Gold Feather to the client. If people understand what I am
saying and think that would be a useful addition to have via the three.js I
might bump it up my project list. But beyond all this are better more
significant problems to solve first. The Gold Feather is done. It doesn't
need to be invented. It just needs to be moved. Anybody could do that.
Is beautiful paper. If have not read it. Reads it. From my former
university indeed it is.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.6932&rep=rep1&type=pdf
I will try and pull my paper together to. LaTex. Just got lots to do.
On Mon, Mar 22, 2021 at 10:15 AM irevdev via Discuss <
discuss@lists.openscad.org> wrote:
@mixotricha, I not sure understand, do you think there's a problem with
my solution?
I don't have a geometry transfer problem because I'm not transferring
geometry only images (which has it's own disadvantages, but one I'm willing
to wear). And I don't a parallel problem as I'm just letting AWS handle
that as it's deployed as a lambda.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Paper is here ...
https://gitlab.com/mixotricha/elixir-makertron/-/blob/71a4a3366a752edf68cb97bae0ffe3948825c620/docs/makertron_white_paper.pdf
On Mon, Mar 22, 2021 at 11:19 AM Damien Towning <connolly.damien@gmail.com>
wrote:
> Depends on the design goal. I am working on a distributed high speed
> OpenSCAD 'parser' for handling large geometrical problems on a distributed
> cluster. This is for large complicated objects. Things like industrial
> plumbing layouts. Streaming an instance of OpenSCAD to a web interface
> would be my worst choice for solving that problem. Is not a problem for a
> small fiddle though to tinker with at small scale. Sooner or later you have
> to scale this on the AWS. Then you learn about the costs. At some point I
> built a distributed cluster on the AWS using the star stuff. Each node held
> a headless OpenSCAD. It ate resources like a swarm of hungry mice. This was
> when I began to ponder metal. I've actually actually built my own dedicated
> cluster with custom FPGA in it and such like to manage my costs and cut out
> fat. I don't want to discourage anybody from going here though. Just trying
> to relay what I have learned. This is work is important. You will also find
> it generalises to a lot of useful other problems. If you think you can
> solve the app on one end and stream it directly to the client on the other
> end problem at scale at some reasonable cost. Then that is great! When I
> looked at this it was my worst possible design choice to implement. However
> as stated what you can do is to reshape the asymmetry you currently have by
> moving the Gold Feather to the client. If people understand what I am
> saying and think that would be a useful addition to have via the three.js I
> might bump it up my project list. But beyond all this are better more
> significant problems to solve first. The Gold Feather is done. It doesn't
> need to be invented. It just needs to be moved. Anybody could do that.
>
> Is beautiful paper. If have not read it. Reads it. From my former
> university indeed it is.
>
>
> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.6932&rep=rep1&type=pdf
>
> I will try and pull my paper together to. LaTex. Just got lots to do.
>
> On Mon, Mar 22, 2021 at 10:15 AM irevdev via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> @mixotricha, I not sure understand, do you think there's a problem with
>> my solution?
>>
>> I don't have a geometry transfer problem because I'm not transferring
>> geometry only images (which has it's own disadvantages, but one I'm willing
>> to wear). And I don't a parallel problem as I'm just letting AWS handle
>> that as it's deployed as a lambda.
>> ------------------------------
>> Sent from the OpenSCAD mailing list archive <http://forum.openscad.org/>
>> at Nabble.com.
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
>
> --
> Damien Towning
>
>
>
--
Damien Towning
JB
Jordan Brown
Mon, Mar 22, 2021 2:30 AM
Remember that clients automatically bring CPU power with them, and it's
CPU power that you don't have to pay for. Anything you can have the
clients do instead of the servers doing it seems like a win.
Remember that clients automatically bring CPU power with them, and it's
CPU power that you don't have to pay for. Anything you can have the
clients do instead of the servers doing it seems like a win.
I
irevdev
Mon, Mar 22, 2021 6:39 AM
Thanks for all the extra context,
I'm certainly going more for community sharing snippets over massive files,
and in terms of costs maybe I'll come to regret my current decisions, but I
think there's a big risk in building something that no one actually wants to
use, so I'd rather validate that before preemptively optimising.
--
Sent from: http://forum.openscad.org/
Thanks for all the extra context,
I'm certainly going more for community sharing snippets over massive files,
and in terms of costs maybe I'll come to regret my current decisions, but I
think there's a big risk in building something that no one actually wants to
use, so I'd rather validate that before preemptively optimising.
--
Sent from: http://forum.openscad.org/
T
Troberg
Mon, Mar 22, 2021 8:22 AM
One thing I don't think I can do there, which is essential for me, is use and
include. Everything I do is based on parts libraries and helper libraries
I've made.
--
Sent from: http://forum.openscad.org/
One thing I don't think I can do there, which is essential for me, is use and
include. Everything I do is based on parts libraries and helper libraries
I've made.
--
Sent from: http://forum.openscad.org/
I
irevdev
Mon, Mar 22, 2021 7:24 PM
Thanks for that Troberg.
Its good to hear what people would like to be able to use. I would like to
offer multi-file support in the editor which would allow you to include
between the files, and I'm also considering adding the libraries listed on
openscad.org so they can be included, but generic code re-use sounds tricky
and am not sure long term, as in should users be able to include code from
someone else project on the website?
--
Sent from: http://forum.openscad.org/
Thanks for that Troberg.
Its good to hear what people would like to be able to use. I would like to
offer multi-file support in the editor which would allow you to include
between the files, and I'm also considering adding the libraries listed on
openscad.org so they can be included, but generic code re-use sounds tricky
and am not sure long term, as in should users be able to include code from
someone else project on the website?
--
Sent from: http://forum.openscad.org/
