Re: WinRT
"Nick Sabalausky" wrote in message news:j62qi9$26i2$1...@digitalmars.com... ...seem to suggest that HTML/JS/etc apps will have roughly the same speed as native C++ apps. If that's true, then it can only mean that Win8 severely gimps the performance of natively-compiled apps. It's not as if they've found some magic technology to install a native-JS-executing CPU into your computer. It looks - Intel parallelized JS by OpenCL https://github.com/RiverTrail/RiverTrail/wiki and just announced with Samsung - Tizen (www.tizen.org) with HTML5/JS as major GUI components builders on top of dead Meego. Oleg.
Re: WinRT
On 2011-09-30 00:13, Nick Sabalausky wrote: "RenatoL" wrote in message news:j62q4v$25tn$1...@digitalmars.com... Eh eh, it may be strange something good come out from MS... but i think this time we could look at this with interest this an object replacement for win32 and the OS exposes it in an "open" way... i believe this is good for D (and Delphi, Scala) I'm not sure it's so good for D. Some of the comments here... http://www.winsupersite.com/blog/supersite-blog-39/windows8/winrt-replacing-win32-140605 ...seem to suggest that HTML/JS/etc apps will have roughly the same speed as native C++ apps. If that's true, then it can only mean that Win8 severely gimps the performance of natively-compiled apps. It's not as if they've found some magic technology to install a native-JS-executing CPU into your computer. That's very hard to believe. Of course, this is all getting *very* speculative at this point. I've watched two video clips from the Build conference about C++, one was about C++ in WinRT. It looks and sounds pretty good to me, although I haven't looked at any other parts of Windows 8. I like the idea of having a completely object oriented system API that you also can share among other languages. Note that it's not often I say something good about Microsoft. -- /Jacob Carlborg
Re: "Sourcing" a script's env into D?
On 2011-09-29 19:31, Nick Sabalausky wrote:
Due to process separation, the following won't work:
script.sh:
#!/bin/sh
SOME_VAR=foobar
test.d:
import std.process;
void main()
{
system("./script.sh");
assert(environment["SOME_VAR"] == "foobar");
}
This, of course, is because the script is run in a totally separate process
(AIUI). The same thing happens in Windows, too.
Is there some way to actually get the env that results from the script? I'm
looking for solutions for both Posix and Windows.
Either you do it how it works in DVM or have the script write out a file
that the parent process reads.
--
/Jacob Carlborg
Re: Why an abstract pointer cannot be used as value in an associate array?
Thanks a lot. This solves the problem. However, it breaks the abstractness. Now in D side, we can call auto v = ab(). This does not make sense, because then &v cannot be used in the C library. I don't understand why when we manipulate AB*, D compiler needs to know the size of struct ab. Moreover, when we use AB*[int], the D compiler complains about there's no opHash defined for AB. I don't think they are necessary at all.
Re: Why an abstract pointer cannot be used as value in an associate array?
The problem is that the void* cannot convert back to AB* when we want to use it in c library. Just don't understand why the cast(AB*)p (p is void *) needs to know the size of AB. Is there any unsafe cast which can blindly cast the pointers?
Re: Simple I know, but could use some help compiling with make
On 9/29/2011 2:39 PM, Nick Sabalausky wrote:
"Roderick Gibson" wrote in message
news:j62nvo$2237$1...@digitalmars.com...
On 9/29/2011 2:15 PM, Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:j62msu$205t$1...@digitalmars.com...
"Roderick Gibson" wrote in message
news:j62d4i$1d8l$1...@digitalmars.com...
It's my first foray into the arcana of makefiles and command line
compiling.
My makefile looks like this:
IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import
LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib
LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib
all:
dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\
$(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES)
I think I just don't know how to give the compiler what it wants. I can
build it manually by simply including the full paths to each of those
libraries, but I'd rather avoid having to do that unless necessary. Is
there something I'm just missing?
build.bat:
@echo off
rdmd --build-only -ofmyApp -IC:\Dlang\dmd2\src\ext\Derelict2\import
-L+C:\Dlang\dmd2\src\ext\Derelict2\lib\
DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib
src/main.d
Note:
1. After the "@echo off", that's supposed to be one line.
2. "rdmd" instead of "dmd"
3. Only one ".d" file is given: The one with main()
4. The ".d" file is the *last* param.
Or to make it a little cleaner:
@echo off
IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import
LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\
LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib
DerelictGLU.lib
EXE_NAME = myApp
rdmd --build-only -of%EXE_NAME% %IMPORT% %LIB_PATHS% %LIB_INCLUDES%
src/main.d
Of course, you can use rdmd with make too, but I've never really liked
dealing with make.
Very cool, thanks for going to all the trouble. It only takes the one
souce file, does rdmd build out other files automatically?
What rdmd does is takes the file with "main()", figures out all the ".d"
files needed, checks if any of them have been changed, and if so, it sends
them all to dmd to be compiled. If you omit the "--build-only" it will also
run the program you built. The full format for rdmd is:
rdmd {params for dmd and rdmd} main.d {params for main.exe}
So if you have:
//main.d
import std.stdio;
void main(string[] args)
{
writeln("Hello", args[1]);
}
Then you can do this:
rdmd main.d Joe
Hello Joe
It's an awesome tool. You can run just "rdmd" by itself to see all it's
options.
Be aware though, rdmd has some issues if you're not using at least DMD
2.055.
Hmm, looks like it would be awesome, unfortunately it spits out a bunch
of "previous definition different" errors on the linker, in relation to
the libraries. Oh well, I seem to be able to get it working with dmd for
now.
Re: WinRT
"RenatoL" wrote in message news:j62q4v$25tn$1...@digitalmars.com... > Eh eh, it may be strange something good come out from MS... but i > think this time we could look at this with interest this an > object replacement for win32 and the OS exposes it in an "open" > way... i believe this is good for D (and Delphi, Scala) I'm not sure it's so good for D. Some of the comments here... http://www.winsupersite.com/blog/supersite-blog-39/windows8/winrt-replacing-win32-140605 ...seem to suggest that HTML/JS/etc apps will have roughly the same speed as native C++ apps. If that's true, then it can only mean that Win8 severely gimps the performance of natively-compiled apps. It's not as if they've found some magic technology to install a native-JS-executing CPU into your computer. Of course, this is all getting *very* speculative at this point.
Re: WinRT
Eh eh, it may be strange something good come out from MS... but i think this time we could look at this with interest this an object replacement for win32 and the OS exposes it in an "open" way... i believe this is good for D (and Delphi, Scala)
Re: WinRT
"RenatoL" wrote in message news:j62nl3$21g5$1...@digitalmars.com... > Hi all. What do you about WinRT? I think this new APIs could be a > very interesting point for D... they are open to any language and > i think that D is perfect to work with them. What's your opinion? > Best regards Hmm, this is the first I've heard of it. Looking at the wikipedia page and winsupersite article, I can imagine it being either very good or irritating and patronizing. Hard to say. But after seeing the Win8 UI videos (and after using both Vista and Win7) I find it very difficult to get excited about anything in Win8. Ouch, I just saw this bit at the end of Paul Thurrott's winsupersite article: "Virtually all of the Microsoft WinRT apps--Mail, Calendar, People, Chat, and so on--are all written in HTML and JavaScript" Apparently all the grown-ups have left Microsoft. Fuck that shit. I'm not touching Win8 with the proverbial ten foot poll.
Re: Simple I know, but could use some help compiling with make
"Roderick Gibson" wrote in message
news:j62nvo$2237$1...@digitalmars.com...
> On 9/29/2011 2:15 PM, Nick Sabalausky wrote:
>> "Nick Sabalausky" wrote in message
>> news:j62msu$205t$1...@digitalmars.com...
>>> "Roderick Gibson" wrote in message
>>> news:j62d4i$1d8l$1...@digitalmars.com...
It's my first foray into the arcana of makefiles and command line
compiling.
My makefile looks like this:
IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import
LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib
LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib
all:
dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\
$(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES)
I think I just don't know how to give the compiler what it wants. I can
build it manually by simply including the full paths to each of those
libraries, but I'd rather avoid having to do that unless necessary. Is
there something I'm just missing?
>>>
>>> build.bat:
>>> @echo off
>>> rdmd --build-only -ofmyApp -IC:\Dlang\dmd2\src\ext\Derelict2\import
>>> -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\
>>> DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib
>>> src/main.d
>>>
>>> Note:
>>>
>>> 1. After the "@echo off", that's supposed to be one line.
>>>
>>> 2. "rdmd" instead of "dmd"
>>>
>>> 3. Only one ".d" file is given: The one with main()
>>>
>>> 4. The ".d" file is the *last* param.
>>>
>>
>> Or to make it a little cleaner:
>>
>> @echo off
>>
>> IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import
>> LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\
>> LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib
>> DerelictGLU.lib
>> EXE_NAME = myApp
>>
>> rdmd --build-only -of%EXE_NAME% %IMPORT% %LIB_PATHS% %LIB_INCLUDES%
>> src/main.d
>>
>> Of course, you can use rdmd with make too, but I've never really liked
>> dealing with make.
>>
>>
>
> Very cool, thanks for going to all the trouble. It only takes the one
> souce file, does rdmd build out other files automatically?
What rdmd does is takes the file with "main()", figures out all the ".d"
files needed, checks if any of them have been changed, and if so, it sends
them all to dmd to be compiled. If you omit the "--build-only" it will also
run the program you built. The full format for rdmd is:
rdmd {params for dmd and rdmd} main.d {params for main.exe}
So if you have:
//main.d
import std.stdio;
void main(string[] args)
{
writeln("Hello", args[1]);
}
Then you can do this:
> rdmd main.d Joe
Hello Joe
>
It's an awesome tool. You can run just "rdmd" by itself to see all it's
options.
Be aware though, rdmd has some issues if you're not using at least DMD
2.055.
Re: Simple I know, but could use some help compiling with make
On 9/29/2011 2:19 PM, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 16:30:54 -0400, Roderick Gibson wrote: On 9/29/2011 1:02 PM, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 15:28:56 -0400, Roderick Gibson wrote: On 9/29/2011 11:52 AM, Andrej Mitrovic wrote: On 9/29/11, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic wrote: No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib That's because +path/to/libs is the search-path parameter for OPTLINK. -L goes before all linker parameters. The same is for Linux. See here: http://www.digitalmars.com/d/2.0/dmd-windows.html -Steve Right, I misinterpreted the "same for Windows" part, you were referring to -L and you're right. DMD could do some magic and replace -L-L with -L+ on Windows to simplify cross-platform development. I know it sends everything after -L to the linker, but it could make one special case for this. Thanks so much guys, it worked, although it looks like a mutated wildebeest. For the interested: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) Yes, that is TWO backslashes and the empty line between paths and includes is required. Could probably fix it but couldn't figure out how to escape the backslash (to prevent it from escaping the newline). Can you just leave off the last backslash? Again, not too familiar with OPTLINK, so not sure. -Steve Nope, because then the first backslash would be escaping the newline and the linker looks for Derelict2\lib.lib instead of Derelict2\lib\. I mean, leave off the, um... first last backslash too :) LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib -Steve In that case it starts looking for Derelict2\lib.lib instead of Derelict2\lib\
Re: Simple I know, but could use some help compiling with make
On 9/29/2011 2:15 PM, Nick Sabalausky wrote: "Nick Sabalausky" wrote in message news:j62msu$205t$1...@digitalmars.com... "Roderick Gibson" wrote in message news:j62d4i$1d8l$1...@digitalmars.com... It's my first foray into the arcana of makefiles and command line compiling. My makefile looks like this: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\ $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) I think I just don't know how to give the compiler what it wants. I can build it manually by simply including the full paths to each of those libraries, but I'd rather avoid having to do that unless necessary. Is there something I'm just missing? build.bat: @echo off rdmd --build-only -ofmyApp -IC:\Dlang\dmd2\src\ext\Derelict2\import -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\ DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib src/main.d Note: 1. After the "@echo off", that's supposed to be one line. 2. "rdmd" instead of "dmd" 3. Only one ".d" file is given: The one with main() 4. The ".d" file is the *last* param. Or to make it a little cleaner: @echo off IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib EXE_NAME = myApp rdmd --build-only -of%EXE_NAME% %IMPORT% %LIB_PATHS% %LIB_INCLUDES% src/main.d Of course, you can use rdmd with make too, but I've never really liked dealing with make. Very cool, thanks for going to all the trouble. It only takes the one souce file, does rdmd build out other files automatically?
WinRT
Hi all. What do you about WinRT? I think this new APIs could be a very interesting point for D... they are open to any language and i think that D is perfect to work with them. What's your opinion? Best regards
Re: "Sourcing" a script's env into D?
On Thu, 29 Sep 2011 17:02:28 -0400, Nick Sabalausky wrote:
"Graham Fawcett" wrote in message
news:j62ido$1n0s$1...@digitalmars.com...
On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
Due to process separation, the following won't work:
script.sh:
#!/bin/sh
SOME_VAR=foobar
test.d:
import std.process;
void main()
{
system("./script.sh");
assert(environment["SOME_VAR"] == "foobar");
}
This, of course, is because the script is run in a totally separate
process (AIUI). The same thing happens in Windows, too.
Is there some way to actually get the env that results from the script?
I'm looking for solutions for both Posix and Windows.
What about "export SOME_VAR=foobar"?
Still doesn't work.
This only passes the environment to children started after the export is
done. A child process cannot affect a parent process' environment
directly. Nor can a parent affect an already-running child.
-Steve
Re: Simple I know, but could use some help compiling with make
On Thu, 29 Sep 2011 16:30:54 -0400, Roderick Gibson wrote: On 9/29/2011 1:02 PM, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 15:28:56 -0400, Roderick Gibson wrote: On 9/29/2011 11:52 AM, Andrej Mitrovic wrote: On 9/29/11, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic wrote: No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib That's because +path/to/libs is the search-path parameter for OPTLINK. -L goes before all linker parameters. The same is for Linux. See here: http://www.digitalmars.com/d/2.0/dmd-windows.html -Steve Right, I misinterpreted the "same for Windows" part, you were referring to -L and you're right. DMD could do some magic and replace -L-L with -L+ on Windows to simplify cross-platform development. I know it sends everything after -L to the linker, but it could make one special case for this. Thanks so much guys, it worked, although it looks like a mutated wildebeest. For the interested: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) Yes, that is TWO backslashes and the empty line between paths and includes is required. Could probably fix it but couldn't figure out how to escape the backslash (to prevent it from escaping the newline). Can you just leave off the last backslash? Again, not too familiar with OPTLINK, so not sure. -Steve Nope, because then the first backslash would be escaping the newline and the linker looks for Derelict2\lib.lib instead of Derelict2\lib\. I mean, leave off the, um... first last backslash too :) LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib -Steve
Re: Simple I know, but could use some help compiling with make
"Nick Sabalausky" wrote in message news:j62msu$205t$1...@digitalmars.com... > "Roderick Gibson" wrote in message > news:j62d4i$1d8l$1...@digitalmars.com... >> It's my first foray into the arcana of makefiles and command line >> compiling. >> >> My makefile looks like this: >> >> IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import >> LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib >> LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib >> >> all: >> dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\ >> $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) >> >> I think I just don't know how to give the compiler what it wants. I can >> build it manually by simply including the full paths to each of those >> libraries, but I'd rather avoid having to do that unless necessary. Is >> there something I'm just missing? > > build.bat: > @echo off > rdmd --build-only -ofmyApp -IC:\Dlang\dmd2\src\ext\Derelict2\import > -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\ > DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib src/main.d > > Note: > > 1. After the "@echo off", that's supposed to be one line. > > 2. "rdmd" instead of "dmd" > > 3. Only one ".d" file is given: The one with main() > > 4. The ".d" file is the *last* param. > Or to make it a little cleaner: @echo off IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib EXE_NAME = myApp rdmd --build-only -of%EXE_NAME% %IMPORT% %LIB_PATHS% %LIB_INCLUDES% src/main.d Of course, you can use rdmd with make too, but I've never really liked dealing with make.
Re: Simple I know, but could use some help compiling with make
"Roderick Gibson" wrote in message news:j62d4i$1d8l$1...@digitalmars.com... > It's my first foray into the arcana of makefiles and command line > compiling. > > My makefile looks like this: > > IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import > LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib > LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib > > all: > dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\ > $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) > > I think I just don't know how to give the compiler what it wants. I can > build it manually by simply including the full paths to each of those > libraries, but I'd rather avoid having to do that unless necessary. Is > there something I'm just missing? build.bat: @echo off rdmd --build-only -ofmyApp -IC:\Dlang\dmd2\src\ext\Derelict2\import -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\ DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib src/main.d Note: 1. After the "@echo off", that's supposed to be one line. 2. "rdmd" instead of "dmd" 3. Only one ".d" file is given: The one with main() 4. The ".d" file is the *last* param.
Re: "Sourcing" a script's env into D?
"Graham Fawcett" wrote in message
news:j62ido$1n0s$1...@digitalmars.com...
> On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
>
>> Due to process separation, the following won't work:
>>
>> script.sh:
>> #!/bin/sh
>> SOME_VAR=foobar
>>
>> test.d:
>> import std.process;
>> void main()
>> {
>> system("./script.sh");
>> assert(environment["SOME_VAR"] == "foobar");
>> }
>>
>> This, of course, is because the script is run in a totally separate
>> process (AIUI). The same thing happens in Windows, too.
>>
>> Is there some way to actually get the env that results from the script?
>> I'm looking for solutions for both Posix and Windows.
>
> What about "export SOME_VAR=foobar"?
>
Still doesn't work.
Re: "Sourcing" a script's env into D?
"Steven Schveighoffer" wrote in message
news:op.v2k6axvveav7ka@localhost.localdomain...
> On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
>
>> Due to process separation, the following won't work:
>>
>> script.sh:
>> #!/bin/sh
>> SOME_VAR=foobar
>>
>> test.d:
>> import std.process;
>> void main()
>> {
>> system("./script.sh");
>> assert(environment["SOME_VAR"] == "foobar");
>> }
>>
>> This, of course, is because the script is run in a totally separate
>> process
>> (AIUI). The same thing happens in Windows, too.
>>
>> Is there some way to actually get the env that results from the script?
>> I'm
>> looking for solutions for both Posix and Windows.
>
> No. The way it works when you "source" a script from another script is it
> uses the same process to interpret the script file, which sets the
> environment up.
>
Right, that's why I wasn't surpeised about the above not working and put
"Sourcing" in quotes. I was just wondering if there was some way to get the
environment from the end of that process into the current process.
> Since a D program cannot interpret shell script, all you can do is read
> the environment from the script (have it output the environment) and read
> it in:
>
> #!/bin/sh
> SOME_VAR=foobar
> # note this is needed for SOME_VAR to get into the environment
>
> export SOME_VAR
>
> # write all environment variables to the output
> env
>
> test.d:
> import std.process:
> void main()
> {
>processEnv(system("./script.sh")); // need to write the processEnv
> function which processes the output from env.
> }
>
Good idea, that could work.
> I don't know what your real test case looks like, so I can't really
> comment on the approach. If it's simply loading file-defined environment
> variables, there are better ways (as I'm sure you're aware).
>
Yea, I'm not even sure what approach I'll end up taking. Hell, I'm probably
over-engineering it all anyway. FWIW, the scenario is like this:
I was making a shell script for one of my open source projects to help
automate doing releases. The script is supposed to connect to a file server
(generally via sshfs, which is freaking awesome, btw), update some stuff,
and disconnect.
I figured there was no reason not to make the script public, but also that
it would make sence for various reasons to make the connect/disconnect
configurable (and not included). So the way I did it was it to have the
script call the optional (and user-written) serverConnect and
serverDisconnect scripts. The script also needed to know the path to the
specific destination in the server, so I had the serverConnect set that path
as an environment var (or the user could just set the env var elsewhere,
wherever/however they wanted). So my script just sources the serverConnect
script:
http://www.dsource.org/projects/goldie/browser/trunk/updateServerDocs?rev=449
Then I decided to convert the script to D (partly because my script-fu isn't
all that great). Obviously now the env var solution won't work anymore, at
least not quite as easily, so I'm thinking about what to do.
I was about to just change it from an env var to a cmd line param, but I'm
thinking now my whole connect/disconnect system (proud of it as I was) is
totally backwards and over-engineered. I should just assume the computer's
already connected, take the target path as a cmd line param, and let the
user just wrap the whole damn thing in one "connect, run the tool,
disconnect" script however they wish. That seems to make the most sense.
Re: Simple I know, but could use some help compiling with make
Odd, I never have to do double backslashes. Maybe it's a problem with make. Personally I just use batch files, I kind of got used to them for simple projects. For everything else a D script is my handy tool.
Re: Simple I know, but could use some help compiling with make
On 9/29/2011 1:02 PM, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 15:28:56 -0400, Roderick Gibson wrote: On 9/29/2011 11:52 AM, Andrej Mitrovic wrote: On 9/29/11, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic wrote: No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib That's because +path/to/libs is the search-path parameter for OPTLINK. -L goes before all linker parameters. The same is for Linux. See here: http://www.digitalmars.com/d/2.0/dmd-windows.html -Steve Right, I misinterpreted the "same for Windows" part, you were referring to -L and you're right. DMD could do some magic and replace -L-L with -L+ on Windows to simplify cross-platform development. I know it sends everything after -L to the linker, but it could make one special case for this. Thanks so much guys, it worked, although it looks like a mutated wildebeest. For the interested: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) Yes, that is TWO backslashes and the empty line between paths and includes is required. Could probably fix it but couldn't figure out how to escape the backslash (to prevent it from escaping the newline). Can you just leave off the last backslash? Again, not too familiar with OPTLINK, so not sure. -Steve Nope, because then the first backslash would be escaping the newline and the linker looks for Derelict2\lib.lib instead of Derelict2\lib\.
Re: Simple I know, but could use some help compiling with make
On Thu, 29 Sep 2011 15:28:56 -0400, Roderick Gibson wrote: On 9/29/2011 11:52 AM, Andrej Mitrovic wrote: On 9/29/11, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic wrote: No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib That's because +path/to/libs is the search-path parameter for OPTLINK. -L goes before all linker parameters. The same is for Linux. See here: http://www.digitalmars.com/d/2.0/dmd-windows.html -Steve Right, I misinterpreted the "same for Windows" part, you were referring to -L and you're right. DMD could do some magic and replace -L-L with -L+ on Windows to simplify cross-platform development. I know it sends everything after -L to the linker, but it could make one special case for this. Thanks so much guys, it worked, although it looks like a mutated wildebeest. For the interested: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) Yes, that is TWO backslashes and the empty line between paths and includes is required. Could probably fix it but couldn't figure out how to escape the backslash (to prevent it from escaping the newline). Can you just leave off the last backslash? Again, not too familiar with OPTLINK, so not sure. -Steve
Re: "Sourcing" a script's env into D?
On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
Due to process separation, the following won't work:
script.sh:
#!/bin/sh
SOME_VAR=foobar
test.d:
import std.process;
void main()
{
system("./script.sh");
assert(environment["SOME_VAR"] == "foobar");
}
This, of course, is because the script is run in a totally separate
process
(AIUI). The same thing happens in Windows, too.
Is there some way to actually get the env that results from the script?
I'm
looking for solutions for both Posix and Windows.
No. The way it works when you "source" a script from another script is it
uses the same process to interpret the script file, which sets the
environment up.
Since a D program cannot interpret shell script, all you can do is read
the environment from the script (have it output the environment) and read
it in:
#!/bin/sh
SOME_VAR=foobar
# note this is needed for SOME_VAR to get into the environment
export SOME_VAR
# write all environment variables to the output
env
test.d:
import std.process:
void main()
{
processEnv(system("./script.sh")); // need to write the processEnv
function which processes the output from env.
}
I don't know what your real test case looks like, so I can't really
comment on the approach. If it's simply loading file-defined environment
variables, there are better ways (as I'm sure you're aware).
-Steve
Re: "Sourcing" a script's env into D?
On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
> Due to process separation, the following won't work:
>
> script.sh:
> #!/bin/sh
> SOME_VAR=foobar
>
> test.d:
> import std.process;
> void main()
> {
> system("./script.sh");
> assert(environment["SOME_VAR"] == "foobar");
> }
>
> This, of course, is because the script is run in a totally separate
> process (AIUI). The same thing happens in Windows, too.
>
> Is there some way to actually get the env that results from the script?
> I'm looking for solutions for both Posix and Windows.
What about "export SOME_VAR=foobar"?
Best,
Graham
Re: Simple I know, but could use some help compiling with make
On 9/29/2011 11:52 AM, Andrej Mitrovic wrote: On 9/29/11, Steven Schveighoffer wrote: On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic wrote: No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib That's because +path/to/libs is the search-path parameter for OPTLINK. -L goes before all linker parameters. The same is for Linux. See here: http://www.digitalmars.com/d/2.0/dmd-windows.html -Steve Right, I misinterpreted the "same for Windows" part, you were referring to -L and you're right. DMD could do some magic and replace -L-L with -L+ on Windows to simplify cross-platform development. I know it sends everything after -L to the linker, but it could make one special case for this. Thanks so much guys, it worked, although it looks like a mutated wildebeest. For the interested: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -L+C:\Dlang\dmd2\src\ext\Derelict2\lib\\ LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib DerelictGLU.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) Yes, that is TWO backslashes and the empty line between paths and includes is required. Could probably fix it but couldn't figure out how to escape the backslash (to prevent it from escaping the newline).
Re: Simple I know, but could use some help compiling with make
On 9/29/11, Steven Schveighoffer wrote: > On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic > wrote: > >> No it's not the same for Windows. On Windows you have to use -L+, e.g.: >> >> dmd myfile.d -L+path/to/libs mylib.lib > > That's because +path/to/libs is the search-path parameter for OPTLINK. -L > goes before all linker parameters. The same is for Linux. > > See here: http://www.digitalmars.com/d/2.0/dmd-windows.html > > -Steve > Right, I misinterpreted the "same for Windows" part, you were referring to -L and you're right. DMD could do some magic and replace -L-L with -L+ on Windows to simplify cross-platform development. I know it sends everything after -L to the linker, but it could make one special case for this.
Re: Simple I know, but could use some help compiling with make
On Thu, 29 Sep 2011 14:32:28 -0400, Andrej Mitrovic wrote: No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib That's because +path/to/libs is the search-path parameter for OPTLINK. -L goes before all linker parameters. The same is for Linux. See here: http://www.digitalmars.com/d/2.0/dmd-windows.html -Steve
Re: Simple I know, but could use some help compiling with make
Documented here: http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#PassingsearchdirectoriesforstaticlibraryfilestoOptlink Damn what a big hashtag, lol.
Re: Simple I know, but could use some help compiling with make
No it's not the same for Windows. On Windows you have to use -L+, e.g.: dmd myfile.d -L+path/to/libs mylib.lib
Re: Simple I know, but could use some help compiling with make
On Thu, 29 Sep 2011 14:23:41 -0400, Roderick Gibson wrote: It's my first foray into the arcana of makefiles and command line compiling. My makefile looks like this: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\ $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) I think I just don't know how to give the compiler what it wants. I can build it manually by simply including the full paths to each of those libraries, but I'd rather avoid having to do that unless necessary. Is there something I'm just missing? Library options start with -L. dmd passes everything after the -L to the linker. What you need to do (I am making a vague guess that you are on windows :) is look up OPTLINK's command line options, then use those options after -L. As one who does not do much on Windows, I can tell you that it's very odd when doing dmd commands on Linux, for example: dmd myfile.d -L-Lpath/to/libs -L-lmylib Note the extra -L prefixes are needed, the same is for Windows. -Steve
Simple I know, but could use some help compiling with make
It's my first foray into the arcana of makefiles and command line compiling. My makefile looks like this: IMPORT = -IC:\Dlang\dmd2\src\ext\Derelict2\import LIB_PATHS = -LC:\Dlang\dmd2\src\ext\Derelict2\lib LIB_INCLUDES = DerelictSDL.lib DerelictGL.lib DerelictUtil.lib all: dmd src/main.d src/display.d src/renderdata.d src/vector2d.d\ $(IMPORT) $(LIB_PATHS) $(LIB_INCLUDES) I think I just don't know how to give the compiler what it wants. I can build it manually by simply including the full paths to each of those libraries, but I'd rather avoid having to do that unless necessary. Is there something I'm just missing?
"Sourcing" a script's env into D?
Due to process separation, the following won't work:
script.sh:
#!/bin/sh
SOME_VAR=foobar
test.d:
import std.process;
void main()
{
system("./script.sh");
assert(environment["SOME_VAR"] == "foobar");
}
This, of course, is because the script is run in a totally separate process
(AIUI). The same thing happens in Windows, too.
Is there some way to actually get the env that results from the script? I'm
looking for solutions for both Posix and Windows.
Re: Why an abstract pointer cannot be used as value in an associate array?
On 09/29/2011 01:28 PM, Trass3r wrote:
Am 29.09.2011, 06:51 Uhr, schrieb Cheng Wei :
extern(C) {
struct ab;
}
ab*[int] map;
void main() {
map.clear();
}
Cannot be compiled. Why?
Thanks.
Just use void* for opaque pointers in D.
Or an empty struct.
struct ab{}
Re: Why an abstract pointer cannot be used as value in an associate array?
Am 29.09.2011, 06:51 Uhr, schrieb Cheng Wei :
extern(C) {
struct ab;
}
ab*[int] map;
void main() {
map.clear();
}
Cannot be compiled. Why?
Thanks.
Just use void* for opaque pointers in D.
Re: Why an abstract pointer cannot be used as value in an associate array?
what is the error message ?
Re: Multithreaded file IO?
Jerry , dans le message (digitalmars.D.learn:29830), a écrit : > trav...@phare.normalesup.org (Christophe) writes: > >> Jerry Quinn , dans le message (digitalmars.D.learn:29763), a écrit : >>> What I really want is a shared fifo where the input is lines from a >>> file, and many workers grab something from the fifo. They then push >>> their results into a shared reordering output queue. >> >> My 2 cent advice: >> >> Does the queue really has to be a file ? >> You could read it completely before starting, and then just share >> your instructions as strings for example. > > Yes, these files could be large enough that the memory cost of loading > is an issue. Also, I should be able to do this with input from stdin. > > At this point, I'm trying to figure out how to implement a shared > fifo in D as much as solve my original problem :-) Ok, an idea then could be to make a separate thread that deal with the File object, or a big shared object well protected with a mutex, to ditribute instructions that are as much immutable as possible. Good luck.
