Re: Quit running foreign unittests _
On Thursday, 30 April 2015 at 02:26:19 UTC, Steven Schveighoffer wrote: On 4/29/15 7:43 AM, Dicebot wrote: On Wednesday, 29 April 2015 at 04:53:47 UTC, Steven Schveighoffer wrote: or rdmd -main -unittest - fail to build because the templated unit test doesn't work on your code. Good luck with that. I will create an upstream PR to fix it, problem solved. Have never had a need to do so though, not even a single time. Also : can you please point me again what part of RBT causes compilation slowdowns with version(unittest)? I looked through and found only runtime checks. It's runtime checks that slow down, the unit test compilation is not slow (although it was at one point, but that was for the proper full unit tests). Then test separation + custom runtime filter fixes the issue without language changes. And for that move out of the aggregate + runtime test filtering does what you want. Move out of the aggregate makes it oh so ugly. I want my unit tests right where they belong. Runtime test filtering seems like it adds more complexity to the system unnecessarily. All I need is a way to say yes compiler, I want to run those templated unit tests I imported or no compiler, I don't want to do that. What the default is really isn't important. It is exactly the other way around. Implementing such compile-time filtering would mean adding totally new feature to the language, considerably complicating version system which is very simple right now. And remembering all the issues we had with -allinst it will take a while to figure out. You need something better than ugly to justify such language change. Especially when there is a working solution within existing rules - even if it seems ugly, it is achievable without language changes and addresses the issue.
Re: std.xml2 (collecting features)
On 2015-05-05 12:41, Mario =?UTF-8?B?S3LDtnBsaW4i?= linkr...@github.com wrote: Recently, I compared DOM parsers for an XML files of 100 MByte: 15.8 s tango.text.xml (SiegeLord/Tango-D2) 13.4 s ae.utils.xml (CyberShadow/ae) 8.5 s xml.etree (Python) Either the Tango DOM parser is slow compared to the Tango pull parser, Yes, of course it's slower. The DOM parser creates a DOM as well, which the pull parser doesn't. These other libraries, what kind of parsers are those using? I mean, it's not fair to compare a pull parser against a DOM parser. Could you try D1 Tango as well? Or do you have the benchmark available somewhere? or the D2 port ruined the performance. Might be the case as well, see this comment [1]. [1] http://forum.dlang.org/thread/vsbsxfeciryrdsjhh...@forum.dlang.org?page=3#post-mi8hs8:24b0j:241:40digitalmars.com -- /Jacob Carlborg
Re: Ada to D - an array for storing values of each of the six bits which are sufficient
Realized bitmap, sorry that does not work with DMD 2.067.1: http://vlang.org/docs/Data_Types/Bits_and_Logic.html https://github.com/coverify/vlang/blob/master/src/esdl/data/bvec.d
Re: a success story for D ! !!
On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge!
Re: a success story for D ! !!
On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! half the site is 404, the github account show little activity and information pretty sparse. smells kinda dubios..
Re: a success story for D ! !!
On 6/05/2015 12:37 a.m., ponce wrote: On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! http://proceedings.dvcon-europe.org/2014/presentations_and_papers/T5_5_presentation.pdf
[Issue 11003] Improve .di generation
https://issues.dlang.org/show_bug.cgi?id=11003 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c9972ca53bd20362b615834061939094a30c94b8 Partial fix Issue 11003 - Improve .di generation Use shorthand syntax for eponymous variable templates https://github.com/D-Programming-Language/dmd/commit/13d697077bb9c394a69b11fd191c861b1ce6ed71 Merge pull request #4629 from 9rnsr/fix11003 Partial fix Issue 11003 - Improve .di generation --
[Issue 11003] Improve .di generation
https://issues.dlang.org/show_bug.cgi?id=11003 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: a success story for D ! !!
On 6/05/2015 4:05 a.m., ponce wrote: On Tuesday, 5 May 2015 at 12:43:38 UTC, Rikki Cattermole wrote: On 6/05/2015 12:37 a.m., ponce wrote: On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! http://proceedings.dvcon-europe.org/2014/presentations_and_papers/T5_5_presentation.pdf It's amazing when you think there was such a push-back against UDAs when they were introduced, and here they are, being incredibly useful in all sorts of description task. Personally I was VERY excited to get them.
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Tuesday, 5 May 2015 at 18:13:03 UTC, Iain Buclaw wrote: It should also be possible for compilations to succeed without rt/typeinfo - and for the compiler to not assume they exist (Type::builtinTypeInfo). That would also be most welcome.
Re: Efficiently passing structs
On Tuesday, 5 May 2015 at 21:58:57 UTC, bitwise wrote: On Tue, 05 May 2015 17:33:09 -0400, Namespace rswhi...@gmail.com wrote: I've discussed that so many times... just search for auto / scope ref... ;) It will never happen. See: http://forum.dlang.org/thread/ntsyfhesnywfxvzbe...@forum.dlang.org?page=1 http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1 http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmar...@puremagic.com http://forum.dlang.org/thread/tkzyjhshbqjqxwzpp...@forum.dlang.org#post-mailman.2965.1356319786.5162.digitalmars-d-learn:40puremagic.com http://forum.dlang.org/thread/hga1jl$18hp$1...@digitalmars.com I did read some of these. Has anyone brought up simply allowing in ref or const scope ref to accept rvalues? If DIPs 69 and 25 were implemented, I don't see why this would be a problem. I agree that const ref should not, but I don't see a problem with const scope ref. I haven't seen a conversation that was strongly in favor of DIP 36. Why hasn't it been rejected? Bit We proposed that in DIP 36: http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1 Some more interesting discussion parts: http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com http://forum.dlang.org/thread/km3k8v$80p$1...@digitalmars.com?page=1 http://forum.dlang.org/thread/cafdvkcvf6g8mc01tds6ydxqczbfp1q-a-oefvk6bgetwciu...@mail.gmail.com As you can see there are debate for ages. Many people of the community really wants a solution, but since Andrei and Walter believe that it brings no real benefit, nothing has changed. I stuck with auto ref + templates if I need lvalues + rvalues (which is often the case in game dev).
Re: opEquals optimized away?
On Tuesday, 5 May 2015 at 05:26:17 UTC, anonymous wrote: because `c is c` Thanks. One can see this documented in http://dlang.org/operatoroverloading.html#equals But 1: how can one override this behavior 2: what is the design reason for this Especially: how can one implement side effects on invoking `==' or `!='? -manfred
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote: Am Tue, 05 May 2015 08:41:13 -0700 schrieb Dan Olson zans.is.for.c...@yahoo.com: Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com writes: If the cost is too much (ie: there is no heap), then we should be able to stop emutls from kicking in by preventing the D frontend from returning true on isThreadLocal calls. Iain, I think something like this would be good in GDC. Makes it so much easier to compile for no thread environments. I'm not really sure about this. It's trivial to implement but it generates a semantic difference which harms code portability (e.g. if you have code where you want a global variable, don't mark it as __gshared and then move to an environment with threads). I'm coming around and feeling inclined to agree with this. One of the things I want to avoid is creatIng an embedded dialect of the D. I hope D for microcontrollers, kernels and such looks very much like the idiomatic D in the application programming domain. What I would like to see, however, is a friendly compiler error like This platform does not support thread-local storage. Please decorate your global variables with __gshared. rather than undefined reference '_d_get_address' from the linker. Mike
Re: Does the compiler check for safe?
On Tuesday, 5 May 2015 at 21:09:45 UTC, Charles Hixson wrote: It was in announce because I made a mistake in posting. Yes of course, in a safe funct just try to call a non-safe one, to call a delegate or even to cast something and you'll be able to verify that by yourself thanks to the error messages.
Re: Good examples of value types
On Tuesday, 5 May 2015 at 20:40:59 UTC, Luís Marques wrote: Hi, For a comparison with the Java language, I'm trying to come up with some good examples of custom types that should be value types (but that must be ref types in Java). I think the most obvious ones are numeric types. So BigNum, MyNum, etc. are good examples because programmers are used to numeric types being value types, and having them suddenly become a ref type just because it's MyNum instead of long is really annoying. Still, could you come up with some type that would really benefit from being a value type but that isn't numeric (or otherwise similar)? Thanks for your help! Luís Let me tell you an actual war story of mine. We have this program that is computationally intensive written in java. Somewhere in the core of the program, we have a LRU cache, with some entries sticking in there, and most entry getting evicted soon enough (typical pareto kind of thing). Problem is, all these entries needs to be value types (we are in java) and, by the time things gets evicted from the LRU cache, they have moved to the old generation. The whole damn thing generate a ton of garbage. The obvious solution is to use value types in the cache, but that not possible. I won't go in the details, but that was a really hard problem to solve, that kept us busy for for longer then it should have because of language limitations. Long story short: value types are useful.
[Issue 11003] Improve .di generation
https://issues.dlang.org/show_bug.cgi?id=11003 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --
Re: std.xml2 (collecting features)
On 5/5/2015 4:16 AM, Richard Webb wrote: Also, profiling showed a lot of time spent in the GC, and the recent improvements in that area might have changed things by now. I haven't read the Tango source code, but the performance of it's xml was supposedly because it did not use the GC, it used slices.
Re: dmd -profile=gc
On 5/5/2015 1:40 PM, Paolo Invernizzi wrote: On Tuesday, 5 May 2015 at 09:30:55 UTC, Walter Bright wrote: On 5/4/2015 10:53 PM, extrawurst wrote: Does it work with a multithreaded application (in contrast to -profile) ? Yes, and -profile was also fixed a week ago to handle multiple threads. Finally! Yah! Ironically, the fix turned out to be easy. The idea came from Andrei.
Re: type switch
On Tuesday, 5 May 2015 at 18:12:42 UTC, Ali Çehreli wrote:
Personally, I haven't felt the need for this becuase usually
there is something different only for one or two specific types.
I don't see that the syntax becomes shorter to warrant a
language addition either. (However, the risk of writing 'else
if' instead of 'else static if' is a real annoyance that comes
with bad consequences.)
Another option is to use template specializations, which can be
mixed-in (in bar() below) or called directly (in foo() below):
void doSomethingSpecial(T : int)()
{
// ...
}
void doSomethingSpecial(T : string)()
{
// ...
}
void foo(T)()
{
doSomethingSpecial!T();
}
void bar(T)()
{
mixin doSomethingSpecial!T;
}
void main()
{
foo!string();
bar!int();
}
Ali
Maybe it will not much shorter, but in some cases, such a design
would look more appropriate than static if.
In addition, the keyword case may be omitted in this design,
which will make it even more short and readable. Such as here:
http://dpaste.dzfl.pl/d6643ec8ccd3
In my opinion, the implementation of such a structure will not
hurt D. While it may be something I do not understand :)
Re: opEquals optimized away?
On 05/05/2015 04:30 PM, Manfred Nowak wrote: On Tuesday, 5 May 2015 at 05:26:17 UTC, anonymous wrote: because `c is c` Thanks. One can see this documented in http://dlang.org/operatoroverloading.html#equals But 1: how can one override this behavior There is now way in D other than changing the implementation: https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L141 (There is also object.di there but I think changing the function above should be sufficient.) 2: what is the design reason for this I am guessing: - For correctness, an object should be equal to itself - Preventing memory errors when the left-hand side object is null. - Reducing boilerplate Especially: how can one implement side effects on invoking `==' or `!='? -manfred Can you use a member function instead as in c.eq(c)? Ali
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Maybe it's stupid question, but is there any chance to get D on AVR(8/16 bit)?
Re: Efficiently passing structs
On Tue, 05 May 2015 18:58:34 -0400, Namespace rswhi...@gmail.com wrote: On Tuesday, 5 May 2015 at 21:58:57 UTC, bitwise wrote: On Tue, 05 May 2015 17:33:09 -0400, Namespace rswhi...@gmail.com wrote: I've discussed that so many times... just search for auto / scope ref... ;) It will never happen. See: http://forum.dlang.org/thread/ntsyfhesnywfxvzbe...@forum.dlang.org?page=1 http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1 http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmar...@puremagic.com http://forum.dlang.org/thread/tkzyjhshbqjqxwzpp...@forum.dlang.org#post-mailman.2965.1356319786.5162.digitalmars-d-learn:40puremagic.com http://forum.dlang.org/thread/hga1jl$18hp$1...@digitalmars.com I did read some of these. Has anyone brought up simply allowing in ref or const scope ref to accept rvalues? If DIPs 69 and 25 were implemented, I don't see why this would be a problem. I agree that const ref should not, but I don't see a problem with const scope ref. I haven't seen a conversation that was strongly in favor of DIP 36. Why hasn't it been rejected? Bit We proposed that in DIP 36: http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1 Some more interesting discussion parts: http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com http://forum.dlang.org/thread/km3k8v$80p$1...@digitalmars.com?page=1 http://forum.dlang.org/thread/cafdvkcvf6g8mc01tds6ydxqczbfp1q-a-oefvk6bgetwciu...@mail.gmail.com Awesome, thanks for the links. I haven't read all of these yet. Many people of the community really wants a solution +1 I stuck with auto ref + templates if I need lvalues + rvalues (which is often the case in game dev). Yeah... structs/template-auto-ref is fine for matrices, vectors, quaternions, colors, etc, but I'm not gonna be able to get away with that for any kind of shared assets like textures, materials, etc, etc.. so I hope this eventually gets fixed. but since Andrei and Walter believe that it brings no real benefit, nothing has changed. I suppose this is like the C++ argument always use std::vector instead of std::list because CACHE!, but there's a time and place for everything.. Bit
Re: type switch
On Tuesday, 5 May 2015 at 18:37:52 UTC, Justin Whear wrote: How's this? http://dpaste.dzfl.pl/d6643ec8ccd3 Yes, something like that. In my opinion, it's really easier than static if in some cases.
Re: dub: Missing package description for package at ..\memutils\
Updating DUB to git version helped. Latest release version have next issue https://github.com/D-Programming-Language/dub/issues/535
dub: Missing package description for package at ..\memutils\
After some days of holidays I am back to home, and run my project. After it I got very strange error: dub Error executing command run: Missing package description for package at ..\memutils\ I really do not remember that I played with memutils or so. dub.json include only next dependences: dini: =1.0.0, colorize: =1.0.5, ddbc: =0.2.11,
[Issue 14413] Spurious newline in ddoc JSON output for multiple successive line doc comments
https://issues.dlang.org/show_bug.cgi?id=14413 Nick Sabalausky cbkbbej...@mailinator.com changed: What|Removed |Added CC||cbkbbej...@mailinator.com --- Comment #5 from Nick Sabalausky cbkbbej...@mailinator.com --- I'm with Sonke on this. The output should match the input. If there isn't a blank line (ie paragraph break) in the doc comment, then one should NOT be added in the output. If I *DO* want a paragraph break in the output, I can trivially add one in the doc comment. I've had problems with the current behavior as I frequently use that comment style. --
Re: a success story for D ! !!
On Tuesday, 5 May 2015 at 12:21:52 UTC, extrawurst wrote: the github account show little activity But, a fair chunk of code. Maybe there's little activity recently because they consider it done. I haven't committed to the majority of my github things for months, but I still stand by them.
Re: std.xml2 (collecting features)
On Tuesday, 5 May 2015 at 12:10:59 UTC, Jacob Carlborg wrote: Yes, of course it's slower. The DOM parser creates a DOM as well, which the pull parser doesn't. These other libraries, what kind of parsers are those using? I mean, it's not fair to compare a pull parser against a DOM parser. I agree. Most applications will use a DOM parser for convenience, so sacrificing some speed initially in favour of easy-of-use makes a lot of sense. As long as it is possible to improve it later (e.g. use SIMD scanning to find the end of CDATA etc). In my opinion it is rather difficult to build a good API without also using the API in an application in parallel. So it would be a good strategy to build a specific DOM along with writing the XML infrastructure, like SVG/HTML. Also, some parsers, like RapidXML only support a subset of XML. So they cannot be used for comparisons.
Re: Efficiently passing structs
On Tue, 05 May 2015 00:20:15 -0400, rsw0x anonym...@anonymous.com wrote:
it does, auto ref can bind to both lvalues and rvalues. Create the
function with an empty template like so,
import std.stdio;
struct S{
}
void Foo()(auto ref S s){
}
void main(){
S s;
Foo(s);
Foo(S());
}
There might be other ways that I'm unaware of.
Interesting.. Has this always worked? Theres a couple of forum
conversations about trying to get auto ref to work for non-templates.
The main problem seems to be that auto ref wont work for virtual
functions. Also, I don't see how someone could arrive at the above
solution without showing up here and asking first.
Why not just add rvref to D?
D is already bloated.
Some of the discussions about auto ref seem to have arrived at the idea
that adding a keyword is the only way fix this without changing existing
behavior or adding new behavior that would share syntax with old behavior
and be confusing.
Anyways, for my purposes, templates will do fine, so thanks!
Bit
Re: dmd -profile=gc
On Tuesday, 5 May 2015 at 13:55:29 UTC, Temtaime wrote: I have a problem with regexes inside my project. 5376580784 [] std.regex.internal.kickstart.Kickstart!char.ShiftOr.this dmd\windows\bin\..\..\src\phobos\std\regex\internal\kickstart.d:284 Calling of regex's crot with any argument causes that. Problem only exists if my project is compiled without -debug flag. If i try dustmite it then problem dissapears. What do you mean? You need to formulate the test command correctly.
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Mike n...@none.com writes: On Tuesday, 5 May 2015 at 06:39:42 UTC, Dan Olson wrote: LDC Folks: https://github.com/ldc-developers/ldc/issues/781 is currently preventing me from supporting LDC with this runtime. I looked at this and found a workaround and noted it in the above issue link. Many Thanks! I've gotten further thanks to your help, but now I'm stuck on https://github.com/ldc-developers/ldc/issues/925. Mike Mike, Just updated the issue (you probably got an email). It is caused by a change from 2.066 to 2.067 in DMD front end versions, not specific to LDC.
Re: dmd -profile=gc
On Tuesday, 5 May 2015 at 09:30:55 UTC, Walter Bright wrote: On 5/4/2015 10:53 PM, extrawurst wrote: Does it work with a multithreaded application (in contrast to -profile) ? Yes, and -profile was also fixed a week ago to handle multiple threads. Awesome! Looking forward for the next release!!
Re: Efficiently passing structs
On Tue, 05 May 2015 10:44:13 -0400, rsw0x anonym...@anonymous.com wrote: On Tuesday, 5 May 2015 at 14:14:51 UTC, bitwise wrote: Interesting.. Has this always worked? Theres a couple of forum conversations about trying to get auto ref to work for non-templates. The main problem seems to be that auto ref wont work for virtual functions. I know its worked for a while, I often use it when I'm too lazy to put attributes in and just have the templates infer them for me ;) Nice ;) Also, I don't see how someone could arrive at the above solution without showing up here and asking first. You're probably right, maybe someone should submit a PR to https://github.com/p0nce/d-idioms/ I was actually thinking of trying to add it to the table here: http://dlang.org/function.html#parameters It's on the template page, but as it is truly the only way to ensure structs are passed efficiently, it may be a good idea to add a link, or some text on this page as well.
Re: Building DMD on SmartOS
On Tuesday, 5 May 2015 at 05:42:33 UTC, Kai Nacke wrote: BTW: You can by-pass the Solaris ld by setting environment variable LD_ALTEXEC to the ld binary you want to use. Thanks for the tip: I set that to the binutils ld and got almost all of druntime's tests to pass with a 64-bit binary. I only had to comment out the additional druntime tests having to do with exceptions. Maybe that's related to the link error flamencofantasy pasted. I also tried running the phobos unit tests, but I got a ton of link errors, seemingly for stuff that should be there. I'll let someone else track those down. On Tuesday, 5 May 2015 at 14:19:00 UTC, flamencofantasy wrote: However once I import std.stdio and make use of writeln the build fails with the error below; [root@smartmachine ~]# dmd hello.d /opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. /opt/local/dmd/lib/libphobos2.a(file_8e0_5fb.o): In function `_D3std4file15DirIteratorImpl4nextMFZb': std/file.d:(.text._D3std4file15DirIteratorImpl4nextMFZb+0x7d): undefined reference to `readdir64' collect2: error: ld returned 1 exit status --- errorlevel 1 [root@smartmachine ~]# Hmm, I get no output when building and running the sample file sieve.d. If I use core.stdc.stdio.printf instead, it works fine, just not with std.stdio.writefln. I did rebuild dmd, druntime and phobos with the binutils ld. The linker will only be used for dmd, which won't matter since it's C++ anyway. Druntime and phobos are libraries, so the linker is unused until you build an executable that links against them. Should I give up? Obviously dmd and phobos still have some issues to be fixed on Solaris. It all depends on whether you'd like to pitch in on fixing those. Alternatively, you can try building ldc, which Kai has put some effort into getting working on Solaris/x86.
Re: Building DMD on SmartOS
Thanks for the tip! I pointed LD_ALTEXEC to the gnu ld like this; LD_ALTEXEC=/opt/local/x86_64-sun-solaris2.11/bin/ld Now I can compile and build and run a simple D program with no imports. I do get a link error but ld apparently auto corrects it; [root@smartmachine ~]# dmd hello.d /opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. [root@smartmachine ~]# However once I import std.stdio and make use of writeln the build fails with the error below; [root@smartmachine ~]# dmd hello.d /opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. /opt/local/dmd/lib/libphobos2.a(file_8e0_5fb.o): In function `_D3std4file15DirIteratorImpl4nextMFZb': std/file.d:(.text._D3std4file15DirIteratorImpl4nextMFZb+0x7d): undefined reference to `readdir64' collect2: error: ld returned 1 exit status --- errorlevel 1 [root@smartmachine ~]# I did rebuild dmd, druntime and phobos with the binutils ld. Should I give up? Thanks!
Re: Building DMD on SmartOS
It looks like std/file.d needs to be updated to not use the largefile definition on 64-bit mode. On Tue, May 5, 2015 at 9:18 AM, flamencofantasy via Digitalmars-d digitalmars-d@puremagic.com wrote: Thanks for the tip! I pointed LD_ALTEXEC to the gnu ld like this; LD_ALTEXEC=/opt/local/x86_64-sun-solaris2.11/bin/ld Now I can compile and build and run a simple D program with no imports. I do get a link error but ld apparently auto corrects it; [root@smartmachine ~]# dmd hello.d /opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. [root@smartmachine ~]# However once I import std.stdio and make use of writeln the build fails with the error below; [root@smartmachine ~]# dmd hello.d /opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. /opt/local/dmd/lib/libphobos2.a(file_8e0_5fb.o): In function `_D3std4file15DirIteratorImpl4nextMFZb': std/file.d:(.text._D3std4file15DirIteratorImpl4nextMFZb+0x7d): undefined reference to `readdir64' collect2: error: ld returned 1 exit status --- errorlevel 1 [root@smartmachine ~]# I did rebuild dmd, druntime and phobos with the binutils ld. Should I give up? Thanks!
Re: Adding a read primitive to ranges
On Tuesday, 5 May 2015 at 01:28:03 UTC, Freddy wrote:
Wait, Bad example,
void func(R)(R range){//expects range of ubyte
ubyte[] data=range.read(VERY_BIG_NUMBER);
ubyte[] other_data=range.read(OTHER_VERY_BIG_NUMBER);
}
which would be more optimal for a file but still works for
other ranges, compared to looping though the ranges read
appending to data.
How would it be more optimal? As I said, if you pass in
`file.byChunks(some_amount).joiner`, this will still read the
file in large chunks. It's less optimal now because `read` has to
allocate an array on every call (easily avoidable by passing in a
reusable buffer, but still).
Equivalent code with ranges:
auto range = file.byChunks(4096).joiner;
ubyte[] data = range.take(VERY_BIG_NUMBER).array;
ubyte[] other_data = range.take(OTHER_VERY_BIG_NUMBER).array;
Re: dmd -profile=gc
I have a problem with regexes inside my project. 5376580784 [] std.regex.internal.kickstart.Kickstart!char.ShiftOr.this dmd\windows\bin\..\..\src\phobos\std\regex\internal\kickstart.d:284 Calling of regex's crot with any argument causes that. Problem only exists if my project is compiled without -debug flag. If i try dustmite it then problem dissapears. I don't know how i can help to developers but maybe one could investigate. As a workaround i'm using ctRegex.
Re: dmd -profile=gc
*ctor *and then appication terminates with OOM exeption
Re: CTFE enums static assert
On 2015-05-04 22:22:51 +, ketmar said: as i said, `typeid` is runtime feature, so you can't print it with pragma. and tuples aren't exist in runtime, it's compile-time only. i think you are even more confused now. ;-) sorry. No, that makes it much more clearer for me. The compiler should print it: No type. typeid() is run-time only. And everything would be clear. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com writes: If the cost is too much (ie: there is no heap), then we should be able to stop emutls from kicking in by preventing the D frontend from returning true on isThreadLocal calls. Iain, I think something like this would be good in GDC. Makes it so much easier to compile for no thread environments.
Re: Efficiently passing structs
On Tuesday, 5 May 2015 at 14:14:51 UTC, bitwise wrote:
On Tue, 05 May 2015 00:20:15 -0400, rsw0x
anonym...@anonymous.com wrote:
it does, auto ref can bind to both lvalues and rvalues. Create
the function with an empty template like so,
import std.stdio;
struct S{
}
void Foo()(auto ref S s){
}
void main(){
S s;
Foo(s);
Foo(S());
}
There might be other ways that I'm unaware of.
Interesting.. Has this always worked? Theres a couple of forum
conversations about trying to get auto ref to work for
non-templates. The main problem seems to be that auto ref wont
work for virtual functions.
I know its worked for a while, I often use it when I'm too lazy
to put attributes in and just have the templates infer them for
me ;)
Also, I don't see how someone could arrive at the above
solution without showing up here and asking first.
You're probably right, maybe someone should submit a PR to
https://github.com/p0nce/d-idioms/
Re: Linker command
It compiles the example code and links it with supplied libraries, supposedly dallegro bindings.
Re: Efficiently passing structs
I am sorry for this post, I am just testing something.
Re: Efficiently passing structs
On Tue, 05 May 2015 18:27:54 -0400, Gomen go...@asai.jp wrote: I am sorry for this post, I am just testing something. The retired D forum seems to have been re-purposed for testing ;) Bit
Re: type switch
On 05/04/2015 03:48 PM, Dennis Ritchie wrote:
I've been thinking. In D you can write a similar design to the generic
functions or somewhere, use static if:
// -
static if (is(T == short) || is(T == int) || is(T == long)) {
// do anything
} else static if (is(T == real)) {
// ...
} else static if (is(T == char)) {
// ...
} else static if (is(T == string)) {
// ...
} else static if (is(T == int[])) {
// ...
} else {
// ...
}
Why not put in Phobos shorter design type switch:
// -
type switch (T) {
case short, int, long:
// do anything
case real:
// ...
case char:
// ...
case string:
// ...
case int[]:
// ...
default:
// ...
}
This design has been implemented, for example, in Common Lisp (typecase):
http://www.lispworks.com/documentation/lw51/CLHS/Body/m_tpcase.htm
What do you think about this?
Personally, I haven't felt the need for this becuase usually there is
something different only for one or two specific types.
I don't see that the syntax becomes shorter to warrant a language
addition either. (However, the risk of writing 'else if' instead of
'else static if' is a real annoyance that comes with bad consequences.)
Another option is to use template specializations, which can be mixed-in
(in bar() below) or called directly (in foo() below):
void doSomethingSpecial(T : int)()
{
// ...
}
void doSomethingSpecial(T : string)()
{
// ...
}
void foo(T)()
{
doSomethingSpecial!T();
}
void bar(T)()
{
mixin doSomethingSpecial!T;
}
void main()
{
foo!string();
bar!int();
}
Ali
Re: isForwardRange failed to recognise valid forward range
On Monday, 4 May 2015 at 15:08:04 UTC, ketmar wrote: consistency issues tend to be ignored in D, dunno why. C++ become popular not due to it's weirdness, and make D weird and unintuitive will not automatically made it popular. i'd say the opposite. It is a much lesser problem that Phobos is weird than the language, libraries are easy to fix. But yes, I can't think of a single non-framework language that has shown growth over a long period of time without making aesthetics a selling point: Lisp, Haskell, Ruby, Python… Obviously if people are dealing with ugly on the job, they want something clean when they get to pick and choose. Out of curiosity, did you give up on Aliced now that dmd is moving to D from C++?
Re: type switch
How's this? http://dpaste.dzfl.pl/d6643ec8ccd3
Re: Efficiently passing structs
On Tue, 05 May 2015 17:33:09 -0400, Namespace rswhi...@gmail.com wrote: I've discussed that so many times... just search for auto / scope ref... ;) It will never happen. See: http://forum.dlang.org/thread/ntsyfhesnywfxvzbe...@forum.dlang.org?page=1 http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=1 http://forum.dlang.org/thread/mailman.2989.1356370854.5162.digitalmar...@puremagic.com http://forum.dlang.org/thread/tkzyjhshbqjqxwzpp...@forum.dlang.org#post-mailman.2965.1356319786.5162.digitalmars-d-learn:40puremagic.com http://forum.dlang.org/thread/hga1jl$18hp$1...@digitalmars.com I did read some of these. Has anyone brought up simply allowing in ref or const scope ref to accept rvalues? If DIPs 69 and 25 were implemented, I don't see why this would be a problem. I agree that const ref should not, but I don't see a problem with const scope ref. I haven't seen a conversation that was strongly in favor of DIP 36. Why hasn't it been rejected? Bit
Re: Phobos master broken ?
I think I read something (bugzilla issue, source comment, ...) that hinted at libc having to do with it, but I can't find it now. But CentOS 6's libc is indeed behind that of my usual Ubuntu 14.10 (2.12 vs 2.19). Yeah, upgrading Debian from wheezy to jessie solved the issue.
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Am Tue, 05 May 2015 08:41:13 -0700 schrieb Dan Olson zans.is.for.c...@yahoo.com: Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com writes: If the cost is too much (ie: there is no heap), then we should be able to stop emutls from kicking in by preventing the D frontend from returning true on isThreadLocal calls. Iain, I think something like this would be good in GDC. Makes it so much easier to compile for no thread environments. I'm not really sure about this. It's trivial to implement but it generates a semantic difference which harms code portability (e.g. if you have code where you want a global variable, don't mark it as __gshared and then move to an environment with threads).
Re: a success story for D ! !!
On Tuesday, 5 May 2015 at 12:43:38 UTC, Rikki Cattermole wrote: On 6/05/2015 12:37 a.m., ponce wrote: On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! http://proceedings.dvcon-europe.org/2014/presentations_and_papers/T5_5_presentation.pdf It's amazing when you think there was such a push-back against UDAs when they were introduced, and here they are, being incredibly useful in all sorts of description task.
Re: a success story for D ! !!
ponce: Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! Very nice. Bye, bearophile
Re: Efficiently passing structs
On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote: On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: D will move the argument if it can rather than copying it (e.g. if a temporary is being passed in), which reduces the need for worrying about copying like you tend to have to do in C++98, and I think that a lot of D code just doesn't worry about the cost of copying structs. How exactly would you move a struct? Just a memcpy without the postblit? Because D has postblit constructors rather than copy constructors, copying is done by blitting the entire struct and then calling the postlblit constructor afterwards, so unless the postlbit constructor is @disabled, a struct is moveable simply by blitting it and not calling the postblit constructor afterwards. And the compiler can choose to do a move whenever a copy is unnecessary (e.g. return value optimization or when a temporary is passed to a However, if you have a large object that you know is going to be expensive to copy, you're either going to have to use const ref (and thus probably duplicate the function to allow rvalues), or you're going to need to make it a reference type rather than having all of its data live on the stack (either by making it so that the struct contains a pointer to its data or by making it a class). In general, if you're dealing with a type that is going to be expensive to copy, I'd advise making it a reference type over relying on const ref simply because it's less error-prone that way. It's trivial to forget to use ref on a parameter, and generic code won't use it, so it'll generally work better to just make it a reference type. - Jonathan M Davis Something like a Matrix4x4 lives in an awkward place between a class and a struct. Because of the fact that a graphics engine may have to deal with thousands of them per frame, both copying them at function calls, and allocating/collecting thousands of them per frame, are both unacceptable. I was reading up(DIP36, pull requests, forum) and it seems like auto ref was supposed to do something like this. Is there a reason you didn't mention it? You could use auto ref, but then you'd have to templatize the function, since it only works with templated functions, and if you have multiple auto ref parameters, then you'll get a combinatorial explosion of template instantations as you call the function with different combinations of lvalues and rvalues. It's basically like declaring each of the combinations of the function with ref and non-ref parameters, but you don't have to declare them all, and it doesn't work with virtual functions. I didn't mention auto ref mostly just to be simple. But because of that combinatorial explosion (be they declared implicitly via auto ref or manually) is a good reason IMHO to just not worry about this problem in most cases. It's just too tedious to duplicate all functions like that, and using templates isn't always acceptable. In theory, auto ref could work for non-templated functions by making it so that underneath the hood as ref except that any time you passed it an rvalue, it implicitly defined an lvalue for you to pass to the function, but that doesn't match what happens with auto ref with non-templated functions, and changing the behavior for templated functions would be unacceptable, because it would reduce our ability to forward parameters without changing their type, so we'd end up with auto ref doing different things on templated and non-templated functions, which is potentially confusing. And that solution has simply never been agreed upon. I have no idea if it ever will be. Why not just add rvref to D? Because we have too many attributes already. It's actually kind of astonishing that we're getting return ref, because Andrei was adamant that we not add any more parameter attributes, because we simply have too many already. I think that the only reasons that return ref is making it in is because of how it solves a real need and how simple it is, whereas Andrei is not at all convinced that having anything like C++'s const in D is needed. And while it might be nice, for the most part, we _are_ able to mostly write code without worrying about it. - Jonathan M Davis
Re: a success story for D ! !!
On Tuesday, 5 May 2015 at 16:05:16 UTC, ponce wrote: On Tuesday, 5 May 2015 at 12:43:38 UTC, Rikki Cattermole wrote: On 6/05/2015 12:37 a.m., ponce wrote: On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! http://proceedings.dvcon-europe.org/2014/presentations_and_papers/T5_5_presentation.pdf It's amazing when you think there was such a push-back against UDAs when they were introduced, and here they are, being incredibly useful in all sorts of description task. There was pushback on ADU, there was pushback on the way they are specified, and considering half the doc about UDA is antipattern, there is hard data to show that this pushback was justified.
a success story for D ! !!
Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!!
Does the compiler check for safe?
I took some code that was annotated safe, and modified it to use a buffer internal to the class, and an offset counter. Some of the routines adjusted the counter. I forgot to remove the safe annotation. It compiled without error. So... 1) The compiler didn't check for safety 2) It counts as safe if you only modify local-to-the-class variables (and I misunderstood). or 3) This error is only detected on execution But which? (I'm still writing the code, so I can't yet try to execute it, and I took off the safe annotation because after I read the definition in TDPL it seemed a mistaken annotation. But perhaps I misunderstand.)
Re: Adding a read primitive to ranges
How would it be more optimal? As I said, if you pass in `file.byChunks(some_amount).joiner`, this will still read the file in large chunks. It's less optimal now because `read` has to allocate an array on every call (easily avoidable by passing in a reusable buffer, but still). Equivalent code with ranges: auto range = file.byChunks(4096).joiner; ubyte[] data = range.take(VERY_BIG_NUMBER).array; ubyte[] other_data = range.take(OTHER_VERY_BIG_NUMBER).array; The range solution copies from a buffer to a newly allocated array many times, doing many system calls. The read(stream) solution allocates a new array and does one system call. Sorry for the miscommunication.
Re: Does the compiler check for safe?
Can you post the class in question and show where the safe annotation was too?
Re: Does the compiler check for safe?
On Tuesday, 5 May 2015 at 19:32:26 UTC, Adam D. Ruppe wrote: Can you post the class in question and show where the safe annotation was too? And why the f*** is that in announce ?
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Mike n...@none.com writes: Read on GitHub: https://github.com/JinShil/minimal_druntime_experiment There was recently a discussion about how we could create a portable, pay-as-you-go, D runtime to help bring the promise of D to free-standing platforms and devices with tight resource constraints (e.g. microcontrollers). Thread started here: http://forum.dlang.org/post/mhrs4p$31id$1...@digitalmars.com This is cool stuff. Embedded has been the bulk of my software life and is most fun. I see there has been a lot of discussion that I'll have to read up on before I say much more though. * the newlib C library newlib has treated me well in the past, especially being so highly customizable. I think it is a good choice. It would be fun to rewrite it in D, but that perhaps is much work for little immediate benefit. Plea to Compiler Implementers *** We need better control over codegen. TypeInfo and dead-code removal is preventing me from making progress (http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org). I've resorted to compiling to assembly, using sed to hack the assembly, and then compiling the assembly. Things like that make me want to not use D at all. Yeah, this should be improved. How about a -disable-tls option so that when there are no threads and thus no TLS, you can compile exising D code as-is. Otherwise you have to rewrite normal variables to __gshared everywhere (I actually have this option in a ldc fork). LDC Folks: https://github.com/ldc-developers/ldc/issues/781 is currently preventing me from supporting LDC with this runtime. I looked at this and found a workaround and noted it in the above issue link. -- Dan Olson
[Issue 14544] isForwardRange failed to recognise valid forward range
https://issues.dlang.org/show_bug.cgi?id=14544
Jacob Carlborg d...@me.com changed:
What|Removed |Added
CC||d...@me.com
--- Comment #5 from Jacob Carlborg d...@me.com ---
(In reply to Jonathan M Davis from comment #3)
The problem is though that once
it's required to be a property, changing it later risks breaking code. Given
how poorly properties are checked by the compiler, we _might_ be able to
make the change, but we'd have to be careful about it. Regardless, the fact
that isForwardRange is the way it is and requires that save be a property is
very much on purpose.
I'm not exactly sure how is(typeof()) is working in this case but for a
getter, @property doesn't make a difference, regardless if compiled with the
-property flag. Take this code for example:
@property int foo ()
{
return 1;
}
@property void bar (int a)
{
}
void main ()
{
auto a = foo();
auto b = foo;
bar = 3;
bar(4);
}
This code compiles both with and without the -property flag. The only thing
that will not compile is bar = 3 if bar is _not_ marked with @property and
it's compiled with the -property flag.
What we can do what looks to be completely backwards compatible is modify the
isForwardRange constraint to look like this instead:
static assert (is(typeof(r1.save()) == R));
Or to make it more clear:
static assert (is(ReturnType!(save) == R));
These two will work regardless if @property is used on save or if the code is
compiled with -property.
--
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On 5 May 2015 at 08:39, Dan Olson via Digitalmars-d digitalmars-d@puremagic.com wrote: Mike n...@none.com writes: Read on GitHub: https://github.com/JinShil/minimal_druntime_experiment There was recently a discussion about how we could create a portable, pay-as-you-go, D runtime to help bring the promise of D to free-standing platforms and devices with tight resource constraints (e.g. microcontrollers). Thread started here: http://forum.dlang.org/post/mhrs4p$31id$1...@digitalmars.com This is cool stuff. Embedded has been the bulk of my software life and is most fun. I see there has been a lot of discussion that I'll have to read up on before I say much more though. * the newlib C library newlib has treated me well in the past, especially being so highly customizable. I think it is a good choice. It would be fun to rewrite it in D, but that perhaps is much work for little immediate benefit. Plea to Compiler Implementers *** We need better control over codegen. TypeInfo and dead-code removal is preventing me from making progress (http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org). I've resorted to compiling to assembly, using sed to hack the assembly, and then compiling the assembly. Things like that make me want to not use D at all. Yeah, this should be improved. How about a -disable-tls option so that when there are no threads and thus no TLS, you can compile exising D code as-is. Otherwise you have to rewrite normal variables to __gshared everywhere (I actually have this option in a ldc fork). Configure GDC with --disable-tls --disable-threads to get the desired behaviour (disabling only TLS just makes codegen fallback to emulated thread support).
[Issue 14533] Error 43: Not a Valid Library File
https://issues.dlang.org/show_bug.cgi?id=14533 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |INVALID --
Re: Reading bzipped files
On Monday, 4 May 2015 at 20:53:27 UTC, monty wrote: cool. btw (at least GzipByLine) its slw if you compare it to gzcat and pipe it into stdin and use ByLineFast. i think its mainly the buffer appending that suboptimal. Could anyone please point out if this is possible to fix somehow? Is the solution to avoid the GC and do buffer reuse somehow?
Re: Reading bzipped files
On Tuesday, 5 May 2015 at 06:48:36 UTC, Per Nordlöw wrote: Could anyone please point out if this is possible to fix somehow? Is the solution to avoid the GC and do buffer reuse somehow? I *really* need this for reading Gigabytes of DBpedia data...
Re: std.xml2 (collecting features)
Am Tue, 05 May 2015 02:01:50 + schrieb weaselcat weasel...@gmail.com: maybe off-topic, but it would be nice if the standard json,xml, etc etc all had identical interfaces(except for implementation-specific quirks.) This might be something worth discussing if it wasn't already agreed upon. I don't think this needs discussion. It is plain impossible to have a sophisticated JSON parser and a sophisticated XML parser share the same API. Established function names, structural differences in the formats and feature sets differ to much. For example in XML attributes and child elements are used somewhat interchangeably whereas in JSON attributes don't exist. So while in JSON obj.field makes sense in XML you would want to select either an attribute or an element with the name field. -- Marco
[Issue 14533] Error 43: Not a Valid Library File
https://issues.dlang.org/show_bug.cgi?id=14533
--- Comment #4 from donglei do...@putao.com ---
(In reply to Richard Cattermole from comment #3)
(In reply to donglei from comment #2)
(In reply to Richard Cattermole from comment #1)
Just to confirm this is for 64bit builds on Windows? And not the default
of
32bit?
Windows system is 64bit, but dmd is 32bit!
It maybe cased by COFF format, I want to convert it to OMF format, but not
found coffimplib in DMC website.
Could you konw where i can find coffimplib. or where can I download
libmysql.lib for dlang
Thanks!
Assuming you are building for 32bit on Windows then you will be using OMF.
coffimplib is available at http://ftp.digitalmars.com/coffimplib.zip
It solved in windows,
but in debian
pragma (lib, mysqlclient);
extern(System) {
struct MYSQL;
struct MYSQL_RES;
/* typedef */ alias const(ubyte)* cstring;
struct MYSQL_FIELD {
cstring name; /* Name of column */
cstring org_name; /* Original column name, if an alias */
cstring table;/* Table of column if column was a
field */
cstring org_table;/* Org table name, if table was an
alias */
cstring db; /* Database for table */
cstring catalog; /* Catalog for table */
cstring def; /* Default value (set by
mysql_list_fields) */
uint length; /* Width of column (create length) */
uint max_length; /* Max width for selected set */
uint name_length;
uint org_name_length;
uint table_length;
uint org_table_length;
uint db_length;
uint catalog_length;
uint def_length;
uint flags; /* Div flags */
uint decimals; /* Number of decimals in field */
uint charsetnr; /* Character set */
uint type; /* Type of field. See mysql_com.h for types */
// type is actually an enum btw
version(MySQL_51) {
void* extension;
}
}
/* typedef */ alias cstring* MYSQL_ROW;
cstring mysql_get_client_info();
MYSQL* mysql_init(MYSQL*);
uint mysql_errno(MYSQL*);
cstring mysql_error(MYSQL*);
MYSQL* mysql_real_connect(MYSQL*, cstring, cstring, cstring, cstring, uint,
cstring, c_ulong);
int mysql_query(MYSQL*, cstring);
void mysql_close(MYSQL*);
ulong mysql_num_rows(MYSQL_RES*);
uint mysql_num_fields(MYSQL_RES*);
bool mysql_eof(MYSQL_RES*);
ulong mysql_affected_rows(MYSQL*);
ulong mysql_insert_id(MYSQL*);
MYSQL_RES* mysql_store_result(MYSQL*);
MYSQL_RES* mysql_use_result(MYSQL*);
MYSQL_ROW mysql_fetch_row(MYSQL_RES *);
uint* mysql_fetch_lengths(MYSQL_RES*);
MYSQL_FIELD* mysql_fetch_field(MYSQL_RES*);
MYSQL_FIELD* mysql_fetch_fields(MYSQL_RES*);
uint mysql_real_escape_string(MYSQL*, ubyte* to, cstring from, uint
length);
void mysql_free_result(MYSQL_RES*);
}
It does work
Thanks
--
Re: Reading bzipped files
On Tuesday, 5 May 2015 at 06:50:12 UTC, Per Nordlöw wrote: On Tuesday, 5 May 2015 at 06:48:36 UTC, Per Nordlöw wrote: Could anyone please point out if this is possible to fix somehow? Is the solution to avoid the GC and do buffer reuse somehow? I *really* need this for reading Gigabytes of DBpedia data... my approach would be to more or less port the ByLineFast approach. i just haven't had any time to do this yet. maybe this could work too though: https://github.com/biod/BioD/tree/master/bio/core/bgzf also check out: https://github.com/agordon/fileslurp https://github.com/biod/BioD/blob/master/bio/core/utils/bylinefast.d
[Issue 14519] [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #27 from Sobirari Muhomori dfj1es...@sneakemail.com --- If you want to request definite behavior in a fine-grained manner, that's always possible with configurable decoders, they would ignore default behavior if necessary. --
Re: Reading bzipped files
On Tuesday, 5 May 2015 at 07:11:36 UTC, monty wrote: also check out: https://github.com/agordon/fileslurp https://github.com/biod/BioD/blob/master/bio/core/utils/bylinefast.d Thanks!
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Tuesday, 5 May 2015 at 06:56:52 UTC, Iain Buclaw wrote: Configure GDC with --disable-tls --disable-threads to get the desired behaviour (disabling only TLS just makes codegen fallback to emulated thread support). I didn't know this. You mean if I configure with those options, TLS variables will be treated as __gshared? Mike
[Issue 14546] New: ClockType.uptime is not supported by MonoTimeImpl on this system
https://issues.dlang.org/show_bug.cgi?id=14546 Issue ID: 14546 Summary: ClockType.uptime is not supported by MonoTimeImpl on this system Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com Attempting to build dlang.org on a Linux/64 system results in the following error message: ../dmd/src/dmd -conf= -c -w -o- -Isrc -Iimport -version=CoreDdoc -Df/home/dlang/d/dlang.org/web/phobos-prerelease/core_time.html project.ddoc /home/dlang/d/dlang.org/macros.ddoc /home/dlang/d/dlang.org/html.ddoc /home/dlang/d/dlang.org/dlang.org.ddoc /home/dlang/d/dlang.org/.generated/2.067.1.ddoc /home/dlang/d/dlang.org/std.ddoc /home/dlang/d/dlang.org/std_navbar-prerelease.ddoc /home/dlang/d/dlang.org/.generated/modlist-prerelease.ddoc src/core/time.d src/core/time.d(2696): Error: static assert ClockType.uptime is not supported by MonoTimeImpl on this system. --
Re: Reading bzipped files
On Saturday, 2 May 2015 at 13:50:10 UTC, Per Nordlöw wrote: Should probably be built on top of http://code.dlang.org/packages/bzip2 Docs here: http://www.bzip.org/1.0.3/html/hl-interface.html
[Issue 14533] Error 43: Not a Valid Library File
https://issues.dlang.org/show_bug.cgi?id=14533 --- Comment #5 from donglei do...@putao.com --- It works ok! thanks --
Re: What wrong?
On Monday, 4 May 2015 at 01:03:43 UTC, Fyodor Ustinov wrote:
On Saturday, 2 May 2015 at 20:46:32 UTC, Dennis Ritchie wrote:
On Saturday, 2 May 2015 at 19:38:01 UTC, Fyodor Ustinov wrote:
I see it by the lack of 42. :)
But why is this receive breaks down?
import std.stdio;
import std.concurrency;
struct Answer
{
int number = 10;
~this()
{
writeln(number);
}
}
void threadRoutine()
{
receive(
(int value){ } //handle question
);
ownerTid.send( Answer() ); //answer
}
void main()
{
Tid childId = spawn(threadRoutine);
childId.send(100); //question
receive((Answer t) {}); //answer
}
//DMD64 D Compiler v2.067.1
/*
10
10
10
10
10
10
10
10
10
10
10
7080544
10
10
10
*/
[Issue 14530] TickDuration to! is broken
https://issues.dlang.org/show_bug.cgi?id=14530 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Introduced in https://github.com/D-Programming-Language/druntime/pull/1190 --
[Issue 14530] TickDuration to! is broken
https://issues.dlang.org/show_bug.cgi?id=14530 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Severity|major |regression --
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Tuesday, 5 May 2015 at 06:39:42 UTC, Dan Olson wrote: LDC Folks: https://github.com/ldc-developers/ldc/issues/781 is currently preventing me from supporting LDC with this runtime. I looked at this and found a workaround and noted it in the above issue link. Many Thanks! I've gotten further thanks to your help, but now I'm stuck on https://github.com/ldc-developers/ldc/issues/925. Mike
[Issue 14526] GetOptException DDOC needs cleanup
https://issues.dlang.org/show_bug.cgi?id=14526 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/3256 --
Re: std.xml2 (collecting features)
On Monday, 4 May 2015 at 19:31:59 UTC, Jonathan M Davis wrote: Given how D's arrays work, we have the opportunity to have an _extremely_ fast XML parser thanks to slices. Yes, that would be great. XML is a flexible go-to archive, exchange and application format. Things like entities, namespaces and so makes it non-trivial, but being able to conveniently process Inkscape and Open Office files etc would be very useful. One should probably look at what applications generate XML and create some large test files with existing applications.
Re: The most awesome forward to member solution?
That is not exactly what I requested years ago --- http://forum.dlang.org/thread/1330792937.10754.7.camel@jonathan
[Issue 14530] TickDuration to! is broken
https://issues.dlang.org/show_bug.cgi?id=14530 Robert Schadek rburn...@gmail.com changed: What|Removed |Added CC||rburn...@gmail.com --- Comment #2 from Robert Schadek rburn...@gmail.com --- https://github.com/D-Programming-Language/druntime/pull/1234 --
Re: dmd -profile=gc
On Monday, 4 May 2015 at 19:24:57 UTC, Walter Bright wrote: On 5/4/2015 6:06 AM, Andrea Fontana wrote: Can be -profile and -profile=gc mixed together? Yes, and you'll get two reports. So I think they should be called -profile and -profile-gc. Or at least -profile=code -profile=gc (but i guess there's a problem with retro-compatibility) Andrea
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On 5 May 2015 at 09:48, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 5 May 2015 at 06:56:52 UTC, Iain Buclaw wrote: Configure GDC with --disable-tls --disable-threads to get the desired behaviour (disabling only TLS just makes codegen fallback to emulated thread support). I didn't know this. You mean if I configure with those options, TLS variables will be treated as __gshared? Mike I have no control over what the backend does, but if it generates control variables for them (emulated tls), then __get_address would incur a small heap cost when first retrieved. If the cost is too much (ie: there is no heap), then we should be able to stop emutls from kicking in by preventing the D frontend from returning true on isThreadLocal calls.
[Issue 14535] std.net.curl.CurlException should include status line
https://issues.dlang.org/show_bug.cgi?id=14535 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/3257 --
Re: std.mmfile is broken
On Tuesday, 5 May 2015 at 19:53:51 UTC, Freddy wrote: The garbage collector is not required to call class destructors, but Mmfile is a class and could leak memory. http://dlang.org/phobos/std_mmfile.html As far as I know, when a process is terminated, its file handlers are removed by operating system automatically. Since, in destructor method, it only closes the file, even destructor is not called by the GC, it won't be a problem. Also, how else do you think the file will be closed other than destructor? Either it should be done manually, or by destructor.
Re: std.mmfile is broken
On Tuesday, 5 May 2015 at 19:53:51 UTC, Freddy wrote: The garbage collector is not required to call class destructors, but Mmfile is a class and could leak memory. http://dlang.org/phobos/std_mmfile.html This would probably be better reported as a bug using the issue tracker: https://issues.dlang.org/
std.mmfile is broken
The garbage collector is not required to call class destructors, but Mmfile is a class and could leak memory. http://dlang.org/phobos/std_mmfile.html
Re: Efficiently passing structs
On Tue, 05 May 2015 14:49:07 -0400, Ali Çehreli acehr...@yahoo.com wrote: http://ddili.org/ders/d.en/lvalue_rvalue.html#ix_lvalue_rvalue.auto%20ref,%20parameter I've actually stumbled upon this site a few times, and it has been very helpful, so thanks =D Unfortunately though, I had no idea that auto ref was what I was looking for in the first place =/
Re: dmd -profile=gc
On Tuesday, 5 May 2015 at 09:30:55 UTC, Walter Bright wrote: On 5/4/2015 10:53 PM, extrawurst wrote: Does it work with a multithreaded application (in contrast to -profile) ? Yes, and -profile was also fixed a week ago to handle multiple threads. Finally! Yah! /P
Good examples of value types
Hi, For a comparison with the Java language, I'm trying to come up with some good examples of custom types that should be value types (but that must be ref types in Java). I think the most obvious ones are numeric types. So BigNum, MyNum, etc. are good examples because programmers are used to numeric types being value types, and having them suddenly become a ref type just because it's MyNum instead of long is really annoying. Still, could you come up with some type that would really benefit from being a value type but that isn't numeric (or otherwise similar)? Thanks for your help! Luís
Re: a success story for D ! !!
On Tuesday, 5 May 2015 at 17:07:19 UTC, deadalnix wrote: On Tuesday, 5 May 2015 at 16:05:16 UTC, ponce wrote: On Tuesday, 5 May 2015 at 12:43:38 UTC, Rikki Cattermole wrote: On 6/05/2015 12:37 a.m., ponce wrote: On Tuesday, 5 May 2015 at 12:04:39 UTC, Alex Ogheri wrote: Hi guys, did you know this ?? http://vlang.org/ In fact, it gathered quite an enthusiastic appreciation at dvcon in Munich!! Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! http://proceedings.dvcon-europe.org/2014/presentations_and_papers/T5_5_presentation.pdf It's amazing when you think there was such a push-back against UDAs when they were introduced, and here they are, being incredibly useful in all sorts of description task. There was pushback on ADU, there was pushback on the way they are specified, and considering half the doc about UDA is antipattern, there is hard data to show that this pushback was justified. ADU as in Attribute Defined User, obviously :/
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Am Tue, 05 May 2015 02:26:26 + schrieb Mike n...@none.com: Read on GitHub: https://github.com/JinShil/minimal_druntime_experiment There was recently a discussion about how we could create a portable, pay-as-you-go, D runtime to help bring the promise of D to free-standing platforms and devices with tight resource constraints (e.g. microcontrollers). Thread started here: http://forum.dlang.org/post/mhrs4p$31id$1...@digitalmars.com The primary motivation is to create an arm-none-eabi GDC cross-compiler toolchain for programming ARM Cortex-M microcontrollers in D, but I think there's a way to achieve broader platform support by delegating implementation details down the supply chain. I hope to articulate that strategy in this post. To prove the concept, provide a place to start, and discuss ideas, I created the most minimal D runtime I could: https://github.com/JinShil/minimal_druntime_experiment. I've also included Phobos, so we could still have `std.stdio.write` and `std.stdio.writeln` for console output, as every device needs a console for development. Overview ** d ├── phobos │ └── std └── runtime └── rt └── typeinfo ports ├── arm │ └── cortexm4 │ ├── phobosWe │ │ └── phobosPort.d │ └── runtime │ └── runtimePort.d ├── posix │ └── linux │ ├── phobos │ │ └── phobosPort.d │ └── runtime │ ├── c_types.d │ └── runtimePort.d There are two main folders: d and ports. d provides the patform-agnostic code, or code that is relevant to a large number of platforms. The ports directory provides the platform-specific implementation. Building simply requires importing d/runtime, d/phobos, and your platform's hierarchy in the ports folder. At the moment, I've only implemented a Linux 64-bit port and an ARM Cortex-M4 port to illustrate the concept. This is roughly how I wish the official runtime could be structured in the spirit of Issue 11666. The official runtime includes platform-specific bindings in `core.sys` and `stdc`, but I think that is a design anomaly. While a port may find it convenient to use those bindings, they should not be part of the D language's public API. Rather, they should be deported to Deimos, and if needed, imported privately by a platform's port. For the Linux port, I chose to write the platform's system calls in assembly to illustrate that it is not even necessary to use those bindings if one wants to do the due diligence in D. Porting to a New Platform ** The platform-agnostic code in d delgates implementation details to the platform-specific code using `extern(C) extern _d_sys_name` system calls (for lack of a better term). This is how the newlib C library delegates platform-specific implementations: See http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c At the moment, for the sake of demonstration, only 2 system calls have been defined: * `__d_sys_write` - Equivalent to C's `write` system call * `__d_sys_exit` - Equivalent to C's `exit` system call These two system calls allow us to create a simple Hello World. runtimePort.d implements `__d_sys_exit` and phobosPort.d implements the `__d_sys_write`. Putting it all Together Users are not expected to use this code directly. Rather, I envision toolchain, silicon, and board vendors will use this code as a small, but essential part of, their platform's D programming package. For example, a package for the ARM Cortex-M family of MCUs might contain the following: * arm-none-eabi GDC cross-compiler * a library containing compiled code for the d folder in this repository * a library containing the compiled code for the ports/arm/cortexm folders in this repository * cortex-m core startup files * the newlib C library * the C library bindings from Deimos * multilibs from the GNU toolchain. A silicon vendor like ST, may then take that package and add more platform-specific for their family of products: * startup files with interrupt vectors for their peripherals * linker scripts for each of their MCUs * flash memory programmer * library for on-dye peripherals * etc.. A board vendor may choose to create yet another layer on top of the silicon vendor's package. * library for peripherals external to the MCU (external RAM, IO expanders, gyroscope, LCD, etc...) In short, this repository just provides just the foundation to get D working, and delegates to toolchain, silicon, and board vendors to fill in the details for their products. RFC * For those who have stake in this code base (kernel developers, embedded developers, toolchain and package maintainers, etc...) your constructive criticism and ideas are most welcome. I am unsure yet how this will play out, and what
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On 5 May 2015 at 19:38, Johannes Pfau via Digitalmars-d digitalmars-d@puremagic.com wrote: I would probably split the runtime into at least two, probably three parts: * Compiler support library (object.d, gcc/*.d, exception implementation) (module rt/ no module name) * Higher level library (portable, micro) * Hardware specific library (not portable, avr/ stm/) I think some basic portability between microcontrollers is useful. The compiler support library should be only a few 100 lines of code and should be without external dependencies. This way it's also useful for very small platforms (8bit) or use-cases where you inject code into other processes. It's trivial to port: we should have an ansi-c port and native ports should be implementable in 1-2 hours. It should also be possible for compilations to succeed without rt/typeinfo - and for the compiler to not assume they exist (Type::builtinTypeInfo).
[Issue 14549] New: isVirtualMethod does not work well with Github DMD
https://issues.dlang.org/show_bug.cgi?id=14549
Issue ID: 14549
Summary: isVirtualMethod does not work well with Github DMD
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pun...@coverify.org
string foo(T)() {
static if(T.tupleof.length = 0)
return ;
}
class frop{
mixin(foo!(typeof(this)));
static if(__traits(compiles, undefined)) { }
else int bar = 0;
static if(! __traits(isVirtualMethod, this.bar)) { }
}
$ dmd test.d
test.d(10): Error: no property 'bar' for type 'test.frop'
--
Re: [hackathon] ARE WE SLIM YET?
On 5/5/15 3:17 AM, Vladimir Panteleev wrote: On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. http://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/ https://news.ycombinator.com/newest https://twitter.com/D_Programming/status/595659506396352513 https://www.facebook.com/dlang.org/posts/1062776287069385 http://www.reddit.com/r/programming/comments/34yxc1/is_d_slim_yet/ Andrei
Re: Phobos master broken ?
On Monday, 4 May 2015 at 14:32:16 UTC, Martin Krejcirik wrote: I can't seem to build phobos master on linux, unless I revert pull #3014 unittests DMD v2.067-devel-b9dee9e DEBUG std/math.d(2702): Error: number '0x1p-1024' is not representable std/math.d(2705): Error: number '0x1p-1024' is not representable std/math.d(2708): Error: number '0x1p-1024' is not representable std/math.d(2713): Error: number '0x1p-128f' is not representable std/math.d(2716): Error: number '0x1p-128f' is not representable std/math.d(2719): Error: number '0x1p-128f' is not representable make: *** [generated/linux/release/32/libphobos2.a] Error 1 Since it lasts about a month, I wonder if I am the only one having this problem ? I encountered this when working with CentOS 6 (i.e. somewhat outdated). I just commented those asserts out to keep going and forgot about it then. I think I read something (bugzilla issue, source comment, ...) that hinted at libc having to do with it, but I can't find it now. But CentOS 6's libc is indeed behind that of my usual Ubuntu 14.10 (2.12 vs 2.19).
[Issue 14548] New: std.stdio.File should have sync() method (fsync/FlushFileBuffers wrapper)
https://issues.dlang.org/show_bug.cgi?id=14548 Issue ID: 14548 Summary: std.stdio.File should have sync() method (fsync/FlushFileBuffers wrapper) Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: pull Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com https://github.com/D-Programming-Language/phobos/pull/3258 --
[Issue 14406] [REG2.068a] GIT HEAD ignores forward reference and generates wrong code
https://issues.dlang.org/show_bug.cgi?id=14406 --- Comment #6 from Puneet Goel pun...@coverify.org --- Kenji Issue https://issues.dlang.org/show_bug.cgi?id=14549 might be related. Kindly have a look. Regards - Puneet --
