Re: string-ish range/stream from curl ubyte[] chunks?
On Fri, 16 May 2014 18:36:02 -0400, Vlad wrote: On Friday, 16 May 2014 at 21:35:04 UTC, Steven Schveighoffer wrote: On Fri, 16 May 2014 16:57:41 -0400, Vlad wrote: Q: Is anything like this already in use somewhere in the standard library or a project you know? There is an effort by myself and Dmitry Olshansky to create a stream API that looks like a range. I am way behind on getting it to work, but I have something that compiles. The effort is to replace the underlying mechanism for std.stdio (optionally), and to replace std.stream Q2: Or do you have any pointers for what the smallest API would be for a string-like range class? I think Dmitry has a pretty good API. I will hopefully be posting my prototype soon. I hate to say wait for it, because I have been very lousy at getting things finished lately. But I want to have something to show before the conference. The code I have will support all encodings, and provide a range API that works with dchar-like ranges. The idea is to be able to make code that works with both arrays and streams seamlessly. And bonus: Q3: any uses of such a string-ish range in other standard library methods that you can think of and could be contributed to? e.g. suppose this doesn't exist and I / we come up with a proposal of minimal API to consume a string from left to right. I hate for you to duplicate efforts, hold off until we get something workable. Then we can discuss the API. Dmitry's message is here: http://forum.dlang.org/post/l9q66g$2he3$1...@digitalmars.com My updates have not been posted yet to github, I don't want to post half-baked code yet. Stay tuned. -Steve Just to make one thing clear: would this future module work with e.g. the ubyte[] chunks I receive from curl? Most likely. I would expect a curl-based stream to fit right in, it's just passing in bytes. One piece that I haven't quite fleshed out is how to drive the process. In some cases, you are pulling data from the source (traditional stream-based I/O), in other cases, something else is pushing the data (CURL). We need to handle both seamlessly. I admit I have never looked at D's curl package, just used it via C/C++. p.s. Is this the talk? http://dconf.org/2014/talks/olshansky.html That is Dmitry's talk, from the same guy. But I think this is not about his I/O ideas, but his excellent std.regex package. -Steve
Re: Bug with std.string.indexOf and case sensivity
On Saturday, 17 May 2014 at 01:08:47 UTC, Ali Çehreli wrote: On 05/16/2014 05:55 PM, Alexandre L. wrote: > >> I'll try to fetch git head and get everything working. >> >> Alexandre L. > > Nevermind that. > For some reasons, the bug was happening when my main.d file looked like > this: > > import std.stdio; > //import std.string; // will work when imported > > int main() > { > string str = "Les chemises"; > // doesnt work > write(std.string.indexOf(str, "Les", CaseSensivity.yes)); I can't explain right now how it happens but I suspect that there is an implicit conversion issue and your enum literal is taken as the startIdx parameter of one of the many overloads of indexOf. Ali > return 0; > } > > --- > While it works when importing std.string. Note that I was using exactly > the same enum (at least, I thought ?) than std.string > > enum CaseSensivity { no, yes } > > Whatever, it works now. I just need to don't forget to import std.string. > > Alexandre L. That would make perfect sense. Thanks for the help. I'll try to investigate further later. Alexandre L.
Re: Bug with std.string.indexOf and case sensivity
On 05/16/2014 05:55 PM, Alexandre L. wrote: > >> I'll try to fetch git head and get everything working. >> >> Alexandre L. > > Nevermind that. > For some reasons, the bug was happening when my main.d file looked like > this: > > import std.stdio; > //import std.string; // will work when imported > > int main() > { > string str = "Les chemises"; > // doesnt work > write(std.string.indexOf(str, "Les", CaseSensivity.yes)); I can't explain right now how it happens but I suspect that there is an implicit conversion issue and your enum literal is taken as the startIdx parameter of one of the many overloads of indexOf. Ali > return 0; > } > > --- > While it works when importing std.string. Note that I was using exactly > the same enum (at least, I thought ?) than std.string > > enum CaseSensivity { no, yes } > > Whatever, it works now. I just need to don't forget to import std.string. > > Alexandre L.
Re: Bug with std.string.indexOf and case sensivity
I'll try to fetch git head and get everything working. Alexandre L. Nevermind that. For some reasons, the bug was happening when my main.d file looked like this: import std.stdio; //import std.string; // will work when imported int main() { string str = "Les chemises"; // doesnt work write(std.string.indexOf(str, "Les", CaseSensivity.yes)); return 0; } --- While it works when importing std.string. Note that I was using exactly the same enum (at least, I thought ?) than std.string enum CaseSensivity { no, yes } Whatever, it works now. I just need to don't forget to import std.string. Alexandre L.
Re: Bug with std.string.indexOf and case sensivity
On Saturday, 17 May 2014 at 00:31:14 UTC, Ali Çehreli wrote: On 05/16/2014 04:52 PM, Alexandre L. wrote: Hello, I was playing around with indexOf when I noticed that the parameter CaseSensitive seems to have a weird behavior. Let's say the following code: string str = "Les chemises sont sèches"; write(std.string.indexOf(str, "Les")); // Returns 0, as expected write(std.string.indexOf(str, "les", CaseSensitive.no)); // Returns -1 while it should return 0 write(std.string.indexOf(str, "Les", CaseSensitive.yes)); // Returns -1 while it should return 0 I'm using DMD 2.065 and if I am not mistaken, I think it was working fine with DMD 2.064. Or is it that I do not understand what CaseSensitive really do? Alexandre L. All return 0 with dmd git head. Ali Hi Ali, Thanks for your reply. I'm not working with the git head so it seems the issue was probably fixed after? Note that I am compiling as "dmd -w -O -unittest" I'll try to fetch git head and get everything working. Alexandre L.
Re: Bug with std.string.indexOf and case sensivity
On 05/16/2014 04:52 PM, Alexandre L. wrote: Hello, I was playing around with indexOf when I noticed that the parameter CaseSensitive seems to have a weird behavior. Let's say the following code: string str = "Les chemises sont sèches"; write(std.string.indexOf(str, "Les")); // Returns 0, as expected write(std.string.indexOf(str, "les", CaseSensitive.no)); // Returns -1 while it should return 0 write(std.string.indexOf(str, "Les", CaseSensitive.yes)); // Returns -1 while it should return 0 I'm using DMD 2.065 and if I am not mistaken, I think it was working fine with DMD 2.064. Or is it that I do not understand what CaseSensitive really do? Alexandre L. All return 0 with dmd git head. Ali
Bug with std.string.indexOf and case sensivity
Hello, I was playing around with indexOf when I noticed that the parameter CaseSensitive seems to have a weird behavior. Let's say the following code: string str = "Les chemises sont sèches"; write(std.string.indexOf(str, "Les")); // Returns 0, as expected write(std.string.indexOf(str, "les", CaseSensitive.no)); // Returns -1 while it should return 0 write(std.string.indexOf(str, "Les", CaseSensitive.yes)); // Returns -1 while it should return 0 I'm using DMD 2.065 and if I am not mistaken, I think it was working fine with DMD 2.064. Or is it that I do not understand what CaseSensitive really do? Alexandre L.
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 20:28:31 UTC, Tom Browder via Digitalmars-d-learn wrote: On Fri, May 16, 2014 at 2:31 PM, Gary Willoughby via Digitalmars-d-learn wrote: On Friday, 16 May 2014 at 19:17:05 UTC, Dicebot wrote: Using .di is more idiomatic as those are supposed to denote declaration-only interface files (with no implementation). In practice it makes almost no difference though so many people use plain .d by habit. ... That's right. I always use .d files when porting C headers because i just see them as regular D code. I like to classify .di files as D 'headers' generated from pure D libraries (using the -H compiler switch). That's just my opinion though and to be honest i don't think it matters. :) Okay, Dicebot and Gary, that makes good sense I think, thanks. So I should use the ".d" for the binding source files since there will almost certainly be implementation code in them. Best, -Tom Yeah , I do and Deimos does too: https://github.com/D-Programming-Deimos
Re: Objects(from classes) at Compile time? no gc
On Friday, 16 May 2014 at 14:13:28 UTC, Steven Schveighoffer wrote: On Fri, 16 May 2014 02:31:18 -0400, Jacob Carlborg wrote: On 16/05/14 06:59, Taylor Hillegeist wrote: The subject says it all really. i have this example: import core.memory; class fruit{ int value=5; public int getvalue(){ return value; } } int main(string[] args) { GC.disable; static fruit myfruit; return myfruit.getvalue(); } Most of the smart people will see that i want the program to return 5 but I did something dumb and didn't put in the "new" statement? So my question is in longer words "Can I create instances of objects at compile time?" and if not "why not, i could build something (roughly)equivalent out of structs and functions and have it at compile time?" If you create an immutable instance it's possible to create it at compile time: int main(string[] args) { GC.disable; immutable fruit myfruit = new immutable(fruit); pragma(msg, myfruit.getvalue); // will print 5 at compile time return myfruit.getvalue(); } Although, I don't know if it will allocate it during runtime as well. It will not. -Steve Does this work in GDC?
Re: string-ish range/stream from curl ubyte[] chunks?
On Friday, 16 May 2014 at 21:35:04 UTC, Steven Schveighoffer wrote: On Fri, 16 May 2014 16:57:41 -0400, Vlad wrote: Q: Is anything like this already in use somewhere in the standard library or a project you know? There is an effort by myself and Dmitry Olshansky to create a stream API that looks like a range. I am way behind on getting it to work, but I have something that compiles. The effort is to replace the underlying mechanism for std.stdio (optionally), and to replace std.stream Q2: Or do you have any pointers for what the smallest API would be for a string-like range class? I think Dmitry has a pretty good API. I will hopefully be posting my prototype soon. I hate to say wait for it, because I have been very lousy at getting things finished lately. But I want to have something to show before the conference. The code I have will support all encodings, and provide a range API that works with dchar-like ranges. The idea is to be able to make code that works with both arrays and streams seamlessly. And bonus: Q3: any uses of such a string-ish range in other standard library methods that you can think of and could be contributed to? e.g. suppose this doesn't exist and I / we come up with a proposal of minimal API to consume a string from left to right. I hate for you to duplicate efforts, hold off until we get something workable. Then we can discuss the API. Dmitry's message is here: http://forum.dlang.org/post/l9q66g$2he3$1...@digitalmars.com My updates have not been posted yet to github, I don't want to post half-baked code yet. Stay tuned. -Steve Thanks Steve for your prompt reply. This is exactly why I asked on the forums, since it was hard for me to believe I was the only one thinking of this. I would also hate to duplicate the effort, so I'll just code my parser against string and wait to see how your proposal and Dimitry's (I did checked his post, and sounds EXACTLY like the problem I was facing with my toy parser!). Just to make one thing clear: would this future module work with e.g. the ubyte[] chunks I receive from curl? Thanks! p.s. Is this the talk? http://dconf.org/2014/talks/olshansky.html
Re: string-ish range/stream from curl ubyte[] chunks?
On Fri, 16 May 2014 16:57:41 -0400, Vlad wrote: Hello D programmers, I am toying with writing my own HTML parser as a pet project, and I strive to have a range API for the tokenizer and the parser output itself. However it occurs to me that in real-life browsers the advantage of this type of 'streaming' parsing would be given by also having the string that plays as input to the tokenizer treated as a 'stream'/'range'. While D's *string classes do play as ranges, what I want to write is a 'ChunkDecoder' range that would take curl 'byChunk' output and make it consumable by the tokenizer. Now, the problem: string itself has ElementType!string == dchar. Consuming a string a dchar at a time looks like a wasteful operation if e.g. your string is UTF-8 or UTF-16. So, naturally, I would like to use indexOf() - instead of countUntil() - and opSlice (without opDollar?) on my ChunkDecoder (forward) range. Q: Is anything like this already in use somewhere in the standard library or a project you know? There is an effort by myself and Dmitry Olshansky to create a stream API that looks like a range. I am way behind on getting it to work, but I have something that compiles. The effort is to replace the underlying mechanism for std.stdio (optionally), and to replace std.stream Q2: Or do you have any pointers for what the smallest API would be for a string-like range class? I think Dmitry has a pretty good API. I will hopefully be posting my prototype soon. I hate to say wait for it, because I have been very lousy at getting things finished lately. But I want to have something to show before the conference. The code I have will support all encodings, and provide a range API that works with dchar-like ranges. The idea is to be able to make code that works with both arrays and streams seamlessly. And bonus: Q3: any uses of such a string-ish range in other standard library methods that you can think of and could be contributed to? e.g. suppose this doesn't exist and I / we come up with a proposal of minimal API to consume a string from left to right. I hate for you to duplicate efforts, hold off until we get something workable. Then we can discuss the API. Dmitry's message is here: http://forum.dlang.org/post/l9q66g$2he3$1...@digitalmars.com My updates have not been posted yet to github, I don't want to post half-baked code yet. Stay tuned. -Steve
string-ish range/stream from curl ubyte[] chunks?
Hello D programmers, I am toying with writing my own HTML parser as a pet project, and I strive to have a range API for the tokenizer and the parser output itself. However it occurs to me that in real-life browsers the advantage of this type of 'streaming' parsing would be given by also having the string that plays as input to the tokenizer treated as a 'stream'/'range'. While D's *string classes do play as ranges, what I want to write is a 'ChunkDecoder' range that would take curl 'byChunk' output and make it consumable by the tokenizer. Now, the problem: string itself has ElementType!string == dchar. Consuming a string a dchar at a time looks like a wasteful operation if e.g. your string is UTF-8 or UTF-16. So, naturally, I would like to use indexOf() - instead of countUntil() - and opSlice (without opDollar?) on my ChunkDecoder (forward) range. Q: Is anything like this already in use somewhere in the standard library or a project you know? Q2: Or do you have any pointers for what the smallest API would be for a string-like range class? And bonus: Q3: any uses of such a string-ish range in other standard library methods that you can think of and could be contributed to? e.g. suppose this doesn't exist and I / we come up with a proposal of minimal API to consume a string from left to right. Thanks for your time and your suggestions!
Re: idup class
On Friday, 16 May 2014 at 20:36:37 UTC, Ali Çehreli wrote: My apologies. The code was written for an older version of dmd. The simplest fix is to define the constructor as pure: pure this(int num) { this.num = num; } Ali Ahh great thanks guys. No worries Ali, great book, i refer to it all the time :)
Re: idup class
On 05/16/2014 01:37 PM, Steven Schveighoffer wrote: On Fri, 16 May 2014 16:36:36 -0400, Ali Çehreli wrote: Beat you by 8 seconds :) -Steve I am happy to be within one minute. :) Ali
Re: idup class
On 05/16/2014 01:28 PM, Joshua Niehus wrote: > trying to follow: > http://ddili.org/ders/d.en/class.html > > //--- OSX 10.9 DMD 2.065 > module test; > > class Foo { > int num; > > this(int num) { > this.num = num; > } > > Foo dup() const { > return new Foo(this.num); > } > > immutable(Foo) idup() const { > return new immutable(Foo)(this.num); > } > } > > void main() { > auto foo = new Foo(1); > auto mfoo = foo.dup(); > auto ifoo = foo.idup(); > } > > * test.d(15): Error: mutable method test.Foo.this is not callable > using a immutable object > * test.d(15): Error: no constructor for Foo > * Failed: ["dmd", "-v", "-o-", "test.d", "-I."] > //--- > > What am i missing? My apologies. The code was written for an older version of dmd. The simplest fix is to define the constructor as pure: pure this(int num) { this.num = num; } Ali
Re: idup class
On Fri, 16 May 2014 16:36:36 -0400, Ali Çehreli wrote: Beat you by 8 seconds :) -Steve
Re: idup class
On Fri, 16 May 2014 16:28:41 -0400, Joshua Niehus wrote: trying to follow: http://ddili.org/ders/d.en/class.html //--- OSX 10.9 DMD 2.065 module test; class Foo { int num; this(int num) { this.num = num; } Foo dup() const { return new Foo(this.num); } immutable(Foo) idup() const { return new immutable(Foo)(this.num); } } void main() { auto foo = new Foo(1); auto mfoo = foo.dup(); auto ifoo = foo.idup(); } * test.d(15): Error: mutable method test.Foo.this is not callable using a immutable object * test.d(15): Error: no constructor for Foo * Failed: ["dmd", "-v", "-o-", "test.d", "-I."] //--- What am i missing? your constructor needs the immutable tag. this(int num) immutable ... However, you can avoid much of this by tagging things as pure: (untested, but just keep the internals the same) class Foo { int num; this(int num) pure {...} Foo dup() const pure {...} immutable(Foo) idup() const pure {...} } void main() { ... // same implementation } Note that doing this, you do not need to have an idup, this should work: immutable ifoo = foo.dup(); -Steve
idup class
trying to follow: http://ddili.org/ders/d.en/class.html //--- OSX 10.9 DMD 2.065 module test; class Foo { int num; this(int num) { this.num = num; } Foo dup() const { return new Foo(this.num); } immutable(Foo) idup() const { return new immutable(Foo)(this.num); } } void main() { auto foo = new Foo(1); auto mfoo = foo.dup(); auto ifoo = foo.idup(); } * test.d(15): Error: mutable method test.Foo.this is not callable using a immutable object * test.d(15): Error: no constructor for Foo * Failed: ["dmd", "-v", "-o-", "test.d", "-I."] //--- What am i missing?
Re: D Newbie Trying to Use D with Major C Libraries
On Fri, May 16, 2014 at 2:31 PM, Gary Willoughby via Digitalmars-d-learn wrote: > On Friday, 16 May 2014 at 19:17:05 UTC, Dicebot wrote: >> Using .di is more idiomatic as those are supposed to denote >> declaration-only interface files (with no implementation). In practice it >> makes almost no difference though so many people use plain .d by habit. ... > That's right. I always use .d files when porting C headers because i just > see them as regular D code. I like to classify .di files as D 'headers' > generated from pure D libraries (using the -H compiler switch). That's just > my opinion though and to be honest i don't think it matters. :) Okay, Dicebot and Gary, that makes good sense I think, thanks. So I should use the ".d" for the binding source files since there will almost certainly be implementation code in them. Best, -Tom
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 19:17:05 UTC, Dicebot wrote: On Friday, 16 May 2014 at 19:05:25 UTC, Tom Browder via Digitalmars-d-learn wrote: On Fri, May 16, 2014 at 1:05 PM, Gary Willoughby via Digitalmars-d-learn wrote: ... Then take a look at one of my projects in which i've ported C headers to D. https://github.com/nomad-software/tcltk I notice your binding source files have a ".d" suffix. Is that the preferred convention? I'm asking because I saw ".di" used on several D Wiki pages. Best, -Tom Using .di is more idiomatic as those are supposed to denote declaration-only interface files (with no implementation). In practice it makes almost no difference though so many people use plain .d by habit. That's right. I always use .d files when porting C headers because i just see them as regular D code. I like to classify .di files as D 'headers' generated from pure D libraries (using the -H compiler switch). That's just my opinion though and to be honest i don't think it matters. :)
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 19:05:25 UTC, Tom Browder via Digitalmars-d-learn wrote: On Fri, May 16, 2014 at 1:05 PM, Gary Willoughby via Digitalmars-d-learn wrote: ... Then take a look at one of my projects in which i've ported C headers to D. https://github.com/nomad-software/tcltk I notice your binding source files have a ".d" suffix. Is that the preferred convention? I'm asking because I saw ".di" used on several D Wiki pages. Best, -Tom Using .di is more idiomatic as those are supposed to denote declaration-only interface files (with no implementation). In practice it makes almost no difference though so many people use plain .d by habit.
Re: D Newbie Trying to Use D with Major C Libraries
On Fri, May 16, 2014 at 1:05 PM, Gary Willoughby via Digitalmars-d-learn wrote: ... > Then take a look at one of my projects in which i've ported C headers to D. > > https://github.com/nomad-software/tcltk I notice your binding source files have a ".d" suffix. Is that the preferred convention? I'm asking because I saw ".di" used on several D Wiki pages. Best, -Tom
Re: D Newbie Trying to Use D with Major C Libraries
On Fri, May 16, 2014 at 1:05 PM, Gary Willoughby via Digitalmars-d-learn wrote: > On Thursday, 15 May 2014 at 22:25:47 UTC, Tom Browder via .. >> What I have not seen yet is the exact way to build a D program which >> uses D bindings and its matching C library. I have just created a ... > For a start use dub to build D projects, it's becoming the de-facto build > tool. ... Thanks for all the help, Gary. Wow, you have been very busy--quite a record to strive for! Best regards, -Tom
Re: D Newbie Trying to Use D with Major C Libraries
On Fri, May 16, 2014 at 1:19 PM, Alex Herrmann via Digitalmars-d-learn wrote: > On Friday, 16 May 2014 at 10:10:17 UTC, Tom Browder via ... >> Thanks for the suggestion, Frank, but I don't do windows. ... > Monodevelop (open source C# dev platform) has a plugin for D by ... Thanks for the suggestions, Alex, ... > Best of luck spreading D Tom! You're doing the lord's work son. I don't know if it's the Lord's work or not, but I do think D is the better C++ for lots of us (with profuse thanks to Bjarne Stroustrup for C++). Best regards, -Tom
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 10:10:17 UTC, Tom Browder via Digitalmars-d-learn wrote: Thanks for the suggestion, Frank, but I don't do windows. Monodevelop (open source C# dev platform) has a plugin for D by Alexander Bothe called Mono-D which is absolutely fantastic and integrates okay with dub too. There is also an emacs major mode for d (d-mode) which gives basic highlighting and indentation too. I use both all of these tools on my Arch linux set up and they work very well, and Mono-D has some debugging support too. Best of luck spreading D Tom! You're doing the lord's work son. Alex
Re: D Newbie Trying to Use D with Major C Libraries
On Thursday, 15 May 2014 at 22:25:47 UTC, Tom Browder via Digitalmars-d-learn wrote: I am a volunteer developer with the well-known 3D CAD FOSS project BRL-CAD: http://brlcad.org I have wanted to use D for a long time but I hadn't taken the plunge. Yesterday I advertised to the BRL-CAD community my new project to attempt to create D bindings for BRL-CAD's C libraries, and I created a branch for the project. I have been looking for specific information on creating D bindings from C headers for which there seems to be sufficient information available, but I would appreciate recommendations as to the best method. I have successfully built my first pure D program but now need to test the feasibility of my project. What I have not seen yet is the exact way to build a D program which uses D bindings and its matching C library. I have just created a Cookbook page on the D Wiki where I show my first attempt for a real GNU Makefile as an example for the project. The page link is here: http://wiki.dlang.org/Using_C_libraries_for_a_D_program I would appreciate it if an experienced D user would correct that recipe so it should compile the desired binary source correctly (assuming no errors in the input files). Thanks for any help. Best regards, -Tom For a start use dub to build D projects, it's becoming the de-facto build tool. http://code.dlang.org/ Then take a look at one of my projects in which i've ported C headers to D. https://github.com/nomad-software/tcltk In that repo i've included all the C headers as well as their D counterparts for reference. Converting headers is not straightforward when you first start but once you understand the rules it gets easier. Here's some helpful links: http://dlang.org/interfaceToC.html http://www.gamedev.net/page/resources/_/technical/game-programming/binding-d-to-c-r3122 http://forum.dlang.org/thread/qvjjzoxoufxnxzoky...@forum.dlang.org http://forum.dlang.org/thread/wmzqweodmbpkfjbve...@forum.dlang.org http://forum.dlang.org/thread/fzqloumcqbdvnccva...@forum.dlang.org Once the D file is created and imported into your program you just need to link the necessary library and you're good to go. See the `package.json` file in the above repository for how i do it for Posix and Windows. Windows DLL's are supplied in the `dist` directory.
Re: [Rosettacode] Growable slices
On Friday, 16 May 2014 at 15:49:10 UTC, bearophile wrote: monarch_dodra: Arguably, your code allocates a lot. What version (1-2-3) do you mean? Any of the versions where you can see "[c]" or "[b]" where c/b is a char/byte
Re: [Rosettacode] Growable slices
On 05/16/14 17:20, bearophile via Digitalmars-d-learn wrote: > Artur Skawina: > >> Ugh. So how does it perform wrt the D version that I wrote for >> you last time? [1] > > I have done a benchmark with the various version (the first 3 are the ones on > the Rosettacode site, and the #4 is yours): > > lzw1: 0.39 > lzw2: 0.17 > lzw3: 0.21 > lzw4: 0.17 > > I think your comment was about an older version of the first entry, that is > non meant to be fast, just short and simple. While I don't remember the numbers, I did test w/ gdc back then and both of your versions (from that thread) performed very poorly in a micro benchmark - I wasn't exaggerating when I said /an order of magnitude/, there really was a ~10 times perf difference. I didn't read the current entries on that page, so that might no longer apply, if you've modified them since. My point is that this third version that you announced here as almost- idiomatic-D is not even close to that goal; it's more or less a direct translation from C, and not like anything that would be written from scratch in D, hence the "ugh". Your own numbers above suggest that not even the "more efficient" claim is true. > I think the second version is enough. Do you agree? I don't see the point of the third ("C-in-D") one, other than to show how a direct C to D translation would look like. If /I/ was looking for a D code sample, then OUT[] compress(OUT=int, R)(R original) { IDAA!(OUT, const typeof(cast()original.front)[]) dictionary; OUT[] result; size_t l = 1; while (original.length>=l) { if (original.takeExactly(l) in dictionary) { ++l; continue; } result ~= dictionary[original.takeExactly(l-1)]; dictionary[original.takeExactly(l)] = cast(OUT)dictionary.length; original.popFrontN(l-1); l = 1; } return original.empty ? result : (result ~ dictionary[original]); } would have been much more useful than any of the currently available examples... Your #1 is more readable and easier to understand for someone not familiar with D and ranges, but extremely inefficient and not something that anyone would like to use in real life. Many of the rosettacode entries are very misleading and unidiomatic, they give a very wrong picture of the language they're trying to show off. This is probably not specific to D, but true for most of the represented languages. artur
Re: Disabling SSL Verification on std.net.curl
On Friday, 16 May 2014 at 07:37:33 UTC, Mengu wrote: On Friday, 16 May 2014 at 04:58:47 UTC, Jack wrote: std.net.curl.CurlException@std\net\curl.d(3592): problem with the SSL CA cert (path? access rights?) on handle 22D3D68 And since I am only using the program by myself for personal things, I was thinking of disabling SSL Verification to stop it from complaining about the cert. So how do I do it? hi Jack curl has an option called SSL_VERIFYPEER which is supported by etc.c.curl: CurlOption. While setting SSL_VERIFYPEER = 0 can be useful for quickly confirming whether CA certificates are causing the problem, and you seem to be aware of the implications, it is worth emphasising, particularly for anyone finding this thread through a search, that setting SSL_VERIFYPEER = 0 reduces the security of SSL almost to the same point as not using SSL at all! See Section 10 of "The Most Dangerous Code in the World": http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
Re: Array!T and find are slow
On Fri, 16 May 2014 11:36:44 -0400, Jonathan M Davis via Digitalmars-d-learn wrote: On Thu, 15 May 2014 08:04:59 -0300 Ary Borenszweig via Digitalmars-d-learn wrote: Isn't there a way in D to just expand: enforce(cond, "failure"); (or something with a similar syntax) to this, at compile-time: if(!cond) throw new Exception("failure"); I thought D could do this, so enforce should do this instead of using lazy arguments. No. enforce is a function, and the only other things that it could be with that syntax would be other callables (e.g. a lambda, delegate, or functor). I think it *could* optimize properly, and that would be an amazing improvement to the compiler, if someone wants to implement that. Essentially, you need to be able to inline enforce (not a problem since it's a template), and then deduce that the lazy calls can just be moved to where they are used, in this case, only once. This would make a logging library even better too. -Steve
Re: [Rosettacode] Growable slices
monarch_dodra: Arguably, your code allocates a lot. What version (1-2-3) do you mean? I'll give it a shot (next week). I think the LZW entries are OK :) So if you want to work on Rosettacode it's better to write an entry that is missing in D. Bye, bearophile
Re: Array!T and find are slow
On Thu, 15 May 2014 08:04:59 -0300 Ary Borenszweig via Digitalmars-d-learn wrote: > Isn't there a way in D to just expand: > > enforce(cond, "failure"); > > (or something with a similar syntax) to this, at compile-time: > > if(!cond) throw new Exception("failure"); > > I thought D could do this, so enforce should do this instead of using > lazy arguments. No. enforce is a function, and the only other things that it could be with that syntax would be other callables (e.g. a lambda, delegate, or functor). Mixins are the only constructs that can completely replace themselves with another construct. So, I suppose that you could have a function called enforce that returned a string and be able to do something like mixin(enforce("cond", `"failure"`)); and you could probably do something similar with a template mixin. mixin(enforce!(cond, "failure")); might be possible if both of the template parameters were alias parameters. But there's no way to take one piece of code and completely translate it into another piece of code without mixins. To do that probably would have meant using some kind of macros, or that was specifically avoided in D's design. And conceptually, using lazy for enforce is a perfect fit. The problem is with the current implementation of lazy. - Jonathan M Davis
Re: [Rosettacode] Growable slices
On Friday, 16 May 2014 at 15:20:04 UTC, bearophile wrote: Artur Skawina: Ugh. So how does it perform wrt the D version that I wrote for you last time? [1] I have done a benchmark with the various version (the first 3 are the ones on the Rosettacode site, and the #4 is yours): lzw1: 0.39 lzw2: 0.17 lzw3: 0.21 lzw4: 0.17 I think your comment was about an older version of the first entry, that is non meant to be fast, just short and simple. I think the second version is enough. Do you agree? The third version should be more efficient but for such small files it's slower than the second. Bye, bearophile Arguably, your code allocates a lot. To speed it up, arguably, you could store a global immutable string containing characters 0 to char.max + 1. This way, when you build your dictionary (each time you enter compress), you at least don't have to allocate the string, but rather, slice your global immutable. Ditto for the lines "w = [ch];", which allocates, you could instead do "w = gAllChars[ch .. ch + 1]". (or "dict[b] = [b]" etc...) Well, just a quick idea... I'll give it a shot (next week).
Re: Seg fault when calling C code
On 05/16/2014 08:24 AM, Ali Çehreli wrote: > On 05/16/2014 08:15 AM, Andrew Brown wrote: > >void foo(ref int[3] a); // D prototype > Since we know that references are implemented as pointers, 'ref int[3] > a' is passed as a.ptr. Sorry, that's confusing. Yes, it ends up being equal to a.ptr but conceptually, the compiler does not pass .ptr directly; it passes the address of the entire array. Since the address of the entire static array is the same as the address of its first element it equals a.ptr and works perfectly in the C land. Ali
Re: Seg fault when calling C code
I guess my confusion came about because in the page about interfacing with C, there's a static array example where parameters are given in terms D understands: extern (C) { void foo(ref int[3] a); // D prototype } I guess D has no problem translating that into a simple pointer that C can deal with. I assumed the same would be true of dynamic arrays, but maybe the leap is too far? And I've finally got round to seeing the table above, it clearly says that C array is equivalent to D pointer. Sorry for being a time waster.
Re: Seg fault when calling C code
On 05/16/2014 08:15 AM, Andrew Brown wrote: > I guess my confusion came about because in the page about interfacing > with C, there's a static array example where parameters are given in > terms D understands: > > extern (C) > { >void foo(ref int[3] a); // D prototype > } > > I guess D has no problem translating that into a simple pointer that C > can deal with. I assumed the same would be true of dynamic arrays, but > maybe the leap is too far? There is a major difference. A static array is direct equivalent of C arrays when it comes to how they are stored in memory. Static arrays are simply consecutive elements. (Of course, static arrays are superior to C arrays in many other aspects. :)) One difference between C arrays is the fact that static arrays are by-value when passed even to functions. (No more "decaying to pointer to first element" confusion.) Since we know that references are implemented as pointers, 'ref int[3] a' is passed as a.ptr. Since the memory layout is the same as a C array, it works perfectly. On the other hand, dynamic arrays (aka slices) are the equivalent of the following struct: struct Slice(T) { size_t length; T * ptr;// points to an array of elements } Ali
Re: Seg fault when calling C code
On Friday, 16 May 2014 at 14:52:17 UTC, Marc Schütz wrote: On Friday, 16 May 2014 at 11:42:35 UTC, Kagamin wrote: For example, windows headers do use C++ &-references in function signatures and msdn provides code examples using that convention, the equivalent in D is ref. But that's extern(C++), not extern(C)... I guess my confusion came about because in the page about interfacing with C, there's a static array example where parameters are given in terms D understands: extern (C) { void foo(ref int[3] a); // D prototype } I guess D has no problem translating that into a simple pointer that C can deal with. I assumed the same would be true of dynamic arrays, but maybe the leap is too far?
Re: [Rosettacode] Growable slices
Artur Skawina: Ugh. So how does it perform wrt the D version that I wrote for you last time? [1] I have done a benchmark with the various version (the first 3 are the ones on the Rosettacode site, and the #4 is yours): lzw1: 0.39 lzw2: 0.17 lzw3: 0.21 lzw4: 0.17 I think your comment was about an older version of the first entry, that is non meant to be fast, just short and simple. I think the second version is enough. Do you agree? The third version should be more efficient but for such small files it's slower than the second. Bye, bearophile
Re: Seg fault when calling C code
On Friday, 16 May 2014 at 11:42:35 UTC, Kagamin wrote: For example, windows headers do use C++ &-references in function signatures and msdn provides code examples using that convention, the equivalent in D is ref. But that's extern(C++), not extern(C)...
Re: D Newbie Trying to Use D with Major C Libraries
On 16/05/14 11:19, John Colvin wrote: Any plans to get any preprocessor stuff working? Presumably libclang can make this feasible. Yes, eventually. Although, currently libclang doesn't really provide an API for the preprocessor, so that needs to be added. -- /Jacob Carlborg
Re: Objects(from classes) at Compile time? no gc
On Fri, 16 May 2014 02:31:18 -0400, Jacob Carlborg wrote: On 16/05/14 06:59, Taylor Hillegeist wrote: The subject says it all really. i have this example: import core.memory; class fruit{ int value=5; public int getvalue(){ return value; } } int main(string[] args) { GC.disable; static fruit myfruit; return myfruit.getvalue(); } Most of the smart people will see that i want the program to return 5 but I did something dumb and didn't put in the "new" statement? So my question is in longer words "Can I create instances of objects at compile time?" and if not "why not, i could build something (roughly)equivalent out of structs and functions and have it at compile time?" If you create an immutable instance it's possible to create it at compile time: int main(string[] args) { GC.disable; immutable fruit myfruit = new immutable(fruit); pragma(msg, myfruit.getvalue); // will print 5 at compile time return myfruit.getvalue(); } Although, I don't know if it will allocate it during runtime as well. It will not. -Steve
Re: [Rosettacode] Growable slices
Artur Skawina: So how does it perform wrt the D version that I wrote for you last time? [1] [1] http://forum.dlang.org/post/mailman.2132.1353592965.5162.digitalmar...@puremagic.com) From your answer: First, the code above is practically a textbook example on how /not/ to write readable and efficient code. So lets do a saner implementation:< I think the code I wrote is sufficiently readable, and surely efficiency was not its purpose. And November 2012 is lot of time ago, I have forgotten that answer of yours, sorry :-) I'll take a better look at it later today and I'll see if it's useful. Thank you. Bye, bearophile
Re: Seg fault when calling C code
For example, windows headers do use C++ &-references in function signatures and msdn provides code examples using that convention, the equivalent in D is ref.
Re: [Rosettacode] Growable slices
On 05/16/14 11:47, bearophile via Digitalmars-d-learn wrote: >> There are of course ways to implement a really efficient ZLW compressor in >> D, and such implementation could be added as third D entry if it manages to >> be not too much long, > > Third version added: > http://rosettacode.org/wiki/LZW_compression#More_Efficient_Version > > I have tried to make it idiomatic D, but some of the C style is probably > still present. Ugh. So how does it perform wrt the D version that I wrote for you last time? [1] [1] http://forum.dlang.org/post/mailman.2132.1353592965.5162.digitalmar...@puremagic.com) artur
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 09:44:11 UTC, bearophile wrote: John Colvin: Any plans to get any preprocessor stuff working? Do you mean in D? Bye, bearophile i think he means in dstep.
Re: Disabling SSL Verification on std.net.curl
On Friday, 16 May 2014 at 07:37:33 UTC, Mengu wrote: hi Jack curl has an option called SSL_VERIFYPEER which is supported by etc.c.curl: CurlOption. you can simply do the following: import std.stdio; import etc.c.curl : CurlOption; import std.net.curl; void main() { auto conn = HTTP(); conn.handle.set(CurlOption.ssl_verifypeer, 0); writeln(get("https://dlang.org/";, conn)); } if you set the option to 1 you will receive this error: std.net.curl.CurlException@std/net/curl.d(3592): Peer certificate cannot be authenticated with given CA certificates on handle 7F908C01DC00 Never really knew that the C interface of curl had the option. Thanks for the info ..
Re: D Newbie Trying to Use D with Major C Libraries
On Fri, May 16, 2014 at 1:17 AM, Jacob Carlborg via Digitalmars-d-learn wrote: ... > On 15/05/14 23:27, Tom Browder via Digitalmars-d-learn wrote: ... >> I have been looking for specific information on creating D bindings >> from C headers for which there seems to be sufficient information >> available, but I would appreciate recommendations as to the best >> method. ... > You can use DStep [1] to automatically generate bindings. It requires some > manual tweaking afterwards but it will give you a good start. > > [1] https://github.com/jacob-carlborg/dstep Thanks, Jacob. I have seen that, but I've been reluctant to start using that until I get more familiar with D. But I think that is the way to go. Best regards, -Tom
Re: D Newbie Trying to Use D with Major C Libraries
On Thu, May 15, 2014 at 9:56 PM, FrankLike via Digitalmars-d-learn wrote: ... > And use VisualD. Thanks for the suggestion, Frank, but I don't do windows. Best, -Tom
Re: [Rosettacode] Growable slices
There are of course ways to implement a really efficient ZLW compressor in D, and such implementation could be added as third D entry if it manages to be not too much long, Third version added: http://rosettacode.org/wiki/LZW_compression#More_Efficient_Version I have tried to make it idiomatic D, but some of the C style is probably still present. The D code currently still requires five casts, and I have guarded them with asserts, like: assert(tmp >> oBits <= ubyte.max); result[outLen] = cast(ubyte)(tmp >> oBits); Perhaps with some more semantic knowledge of the program it's possible to avoid one or two of those casts. The D code contains a little less "type insanity" than the original C version :-) Bye, bearophile
Re: D Newbie Trying to Use D with Major C Libraries
John Colvin: Any plans to get any preprocessor stuff working? Do you mean in D? Bye, bearophile
Re: D Newbie Trying to Use D with Major C Libraries
On Friday, 16 May 2014 at 06:17:47 UTC, Jacob Carlborg wrote: On 15/05/14 23:27, Tom Browder via Digitalmars-d-learn wrote: I am a volunteer developer with the well-known 3D CAD FOSS project BRL-CAD: http://brlcad.org I have wanted to use D for a long time but I hadn't taken the plunge. Yesterday I advertised to the BRL-CAD community my new project to attempt to create D bindings for BRL-CAD's C libraries, and I created a branch for the project. I have been looking for specific information on creating D bindings from C headers for which there seems to be sufficient information available, but I would appreciate recommendations as to the best method. You can use DStep [1] to automatically generate bindings. It requires some manual tweaking afterwards but it will give you a good start. [1] https://github.com/jacob-carlborg/dstep Any plans to get any preprocessor stuff working? Presumably libclang can make this feasible.
Re: Any chance to avoid monitor field in my class?
"Yuriy" wrote in message news:klosrzuxwmvilupzz...@forum.dlang.org... Ok, i can understand that, but what about this one: http://dpaste.dzfl.pl/6a9961e32e6d It doesn't use d arrays in function interfaces. Should it work? Similar problem, D arrays cannot be mangled correctly with C++ mangling. This compiles: extern(C++) interface I { extern(D): int hi(); } extern(C++) class A(T) : I { extern(D): override int hi() { return 0; } } void main() { A!string a; }
Re: Disabling SSL Verification on std.net.curl
On Friday, 16 May 2014 at 04:58:47 UTC, Jack wrote: A follow up from : http://forum.dlang.org/thread/nsdomtdbqqlylrmgo...@forum.dlang.org I discovered that it was not a C::B issue as I already compiled it with Xamarin Studio and it was still spewing out the error: std.net.curl.CurlException@std\net\curl.d(3592): problem with the SSL CA cert (path? access rights?) on handle 22D3D68 And since I am only using the program by myself for personal things, I was thinking of disabling SSL Verification to stop it from complaining about the cert. So how do I do it? hi Jack curl has an option called SSL_VERIFYPEER which is supported by etc.c.curl: CurlOption. you can simply do the following: import std.stdio; import etc.c.curl : CurlOption; import std.net.curl; void main() { auto conn = HTTP(); conn.handle.set(CurlOption.ssl_verifypeer, 0); writeln(get("https://dlang.org/";, conn)); } if you set the option to 1 you will receive this error: std.net.curl.CurlException@std/net/curl.d(3592): Peer certificate cannot be authenticated with given CA certificates on handle 7F908C01DC00