Command line

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
So will the end result be that they both look in the the directory of the file with the include, and the directory containing the top level file?

On 14 February 2012 20:26, Marius Kintel <[hidden email]> wrote:
On Feb 14, 2012, at 21:21 PM, nop head wrote:

> Why does it behave differently on the command line to the GUI. Don't they use the same code at the point?
>
They use different code for initializing the paths based on the input file (cmd-line vs. file dialog).

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Command line

kintel
Administrator
On Feb 14, 2012, at 21:33 PM, nop head wrote:

> So will the end result be that they both look in the the directory of the file with the include, and the directory containing the top level file?
>
It should be looking only relative to the including file, except if the include path is absolute.

I believe this all worked as expected in the latest release - these bugs have been introduced later due to refactoring of filesystem-related code.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
I don't think the GUI always gets it right currently.

I had a file included from two different directories that was including files itself. I couldn't make it work because the path to those second level includes had to be different depending where it was included from. If the path was always relative to the file with the include statement that should have worked.

On 14 February 2012 20:38, Marius Kintel <[hidden email]> wrote:
On Feb 14, 2012, at 21:33 PM, nop head wrote:

> So will the end result be that they both look in the the directory of the file with the include, and the directory containing the top level file?
>
It should be looking only relative to the including file, except if the include path is absolute.

I believe this all worked as expected in the latest release - these bugs have been introduced later due to refactoring of filesystem-related code.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Command line

kintel
Administrator
On Feb 14, 2012, at 21:44 PM, nop head wrote:

> I had a file included from two different directories that was including files itself. I couldn't make it work because the path to those second level includes had to be different depending where it was included from. If the path was always relative to the file with the include statement that should have worked.
>
I'd be interested in any such non-working case to be able to automate these tests.
To my knowledge, this works as expected.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
I'll see what I can do but I am insanely busy at the moment trying to release Mendel90. I moved all the files to where I wanted them but I couldn't make it work so I moved them all back as I have never had the rules for picking up includes clear in my mind, even in C where I tend to add "-I." I assumed the behaviour was correct and I was trying to do something that would not work. When you said it should always be relative to the file with the include I figured it should have worked but it is a lot of editing and moving to put it back to the broken state.

Basically it was just a file that was included by files in different directories and itself included other files. It behaved like its paths were relative to the file that included it.

On 14 February 2012 21:05, Marius Kintel <[hidden email]> wrote:
On Feb 14, 2012, at 21:44 PM, nop head wrote:

> I had a file included from two different directories that was including files itself. I couldn't make it work because the path to those second level includes had to be different depending where it was included from. If the path was always relative to the file with the include statement that should have worked.
>
I'd be interested in any such non-working case to be able to automate these tests.
To my knowledge, this works as expected.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
Actually it was a mixture of include and use. Is it possible use is different?

I also remember the paths seemed to be cached and did not change when I had changed them, adding to my confusion. 

On 14 February 2012 23:25, nop head <[hidden email]> wrote:
I'll see what I can do but I am insanely busy at the moment trying to release Mendel90. I moved all the files to where I wanted them but I couldn't make it work so I moved them all back as I have never had the rules for picking up includes clear in my mind, even in C where I tend to add "-I." I assumed the behaviour was correct and I was trying to do something that would not work. When you said it should always be relative to the file with the include I figured it should have worked but it is a lot of editing and moving to put it back to the broken state.

Basically it was just a file that was included by files in different directories and itself included other files. It behaved like its paths were relative to the file that included it.


On 14 February 2012 21:05, Marius Kintel <[hidden email]> wrote:
On Feb 14, 2012, at 21:44 PM, nop head wrote:

> I had a file included from two different directories that was including files itself. I couldn't make it work because the path to those second level includes had to be different depending where it was included from. If the path was always relative to the file with the include statement that should have worked.
>
I'd be interested in any such non-working case to be able to automate these tests.
To my knowledge, this works as expected.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Command line

kintel
Administrator
On Feb 15, 2012, at 00:27 AM, nop head wrote:

> Actually it was a mixture of include and use. Is it possible use is different?
>
Yes, there was a different issue with use, and yet another issue with use/include from libraries.

Perhaps you should just wait until I merge that branch I'm working on - that will avoid you re-testing yet another time.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
I will have to release my machine without makefiles. I have people demanding it everyday and people ripping off the idea already  http://www.thingiverse.com/tag:stolenidea 

On 14 February 2012 23:30, Marius Kintel <[hidden email]> wrote:
On Feb 15, 2012, at 00:27 AM, nop head wrote:

> Actually it was a mixture of include and use. Is it possible use is different?
>
Yes, there was a different issue with use, and yet another issue with use/include from libraries.

Perhaps you should just wait until I merge that branch I'm working on - that will avoid you re-testing yet another time.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Command line

kintel
Administrator
In reply to this post by nophead
On Feb 12, 2012, at 22:04 PM, nop head wrote:
>
> Illegal options give a runtime error.
>
This was a bug and is now fixed.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
Thanks.

On 19 February 2012 10:18, Marius Kintel <[hidden email]> wrote:
On Feb 12, 2012, at 22:04 PM, nop head wrote:
>
> Illegal options give a runtime error.
>
This was a bug and is now fixed.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Command line

kintel
Administrator
In reply to this post by nophead
Hi again,

Yes, we most probably need two executables, one in console mode and one in windows mode.
Inkscape uses a neat trick:

http://kaioa.com/node/63

Basically, this is a very small program which handles console output and spawns the real exe.
As nophead pointed out, we could name this openscad.com and it will be preferred over openscad.exe from the Windows cmd-line.

Anyone want to give it a shot?

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
You don't really need that. All that needs to happen is make a copy of openscad.exe called openscad.bin and use editbin to make it a console app. I think it will all work as it should then when the include path stuff is fixed. editbin is part of visual studio, even the free one.

On 19 February 2012 10:32, Marius Kintel <[hidden email]> wrote:
Hi again,

Yes, we most probably need two executables, one in console mode and one in windows mode.
Inkscape uses a neat trick:

http://kaioa.com/node/63

Basically, this is a very small program which handles console output and spawns the real exe.
As nophead pointed out, we could name this openscad.com and it will be preferred over openscad.exe from the Windows cmd-line.

Anyone want to give it a shot?

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Command line

kintel
Administrator
On Feb 19, 2012, at 11:46 AM, nop head wrote:

> You don't really need that. All that needs to happen is make a copy of openscad.exe called openscad.bin and use editbin to make it a console app. I think it will all work as it should then when the include path stuff is fixed. editbin is part of visual studio, even the free one.
>
That's the other alternative - it just feels wrong to ship another 18MB just for that flag.

I say choose whichever solution that motivates someone to do it :)

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Command line

nophead
Presumably all one needs to do is change the line with InkScape.exe to OpenScad.exe and that example should work. I will give it a try this afternoon.

On 19 February 2012 12:16, Marius Kintel <[hidden email]> wrote:
On Feb 19, 2012, at 11:46 AM, nop head wrote:

> You don't really need that. All that needs to happen is make a copy of openscad.exe called openscad.bin and use editbin to make it a console app. I think it will all work as it should then when the include path stuff is fixed. editbin is part of visual studio, even the free one.
>
That's the other alternative - it just feels wrong to ship another 18MB just for that flag.

I say choose whichever solution that motivates someone to do it :)

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

12