Re: [GSoC] Precise GC
On Monday, 17 October 2016 at 02:59:15 UTC, Dsby wrote: On Friday, 14 October 2016 at 03:26:31 UTC, FrankLike wrote: On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote: Hi everyone, I know I'm super late to the party for this, and sorry for that. While my work on the precise GC didn't go as planned, it is closer than it was to be getting merged. [...] On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote: Hi,how about the precise GC, now? I want to known too. I was asked the same question on github, but I'll answer it here too with a couple more details. I've done a little work, but not enough to getit finished. I started school a couple of weeks ago and I'm still trying to get my schedule figured out, but I'm hoping to start putting some regular effort into it starting next week.
Re: D Uniform initialization {}
On Sunday, 23 October 2016 at 01:31:47 UTC, Seb wrote: On Saturday, 22 October 2016 at 21:26:53 UTC, Patric Dexheimer wrote: S[] s = [{ 1, 2 }]; Nice, did´n knew that it worked. On Friday, 21 October 2016 at 21:41:16 UTC, Daniel Kozak wrote: Because there is no need. In c++ it is disaster because there is milion way how to initialize something, it is really hard to understand and inconsistent I never really felt lost about it with c++, but the argument holds true anyway :) There has been a abandoned proposal for struct initialization: https://github.com/dlang/DIPs/pull/22 It has been closed only because of inactivity.
Re: D Uniform initialization {}
On Saturday, 22 October 2016 at 21:26:53 UTC, Patric Dexheimer wrote: S[] s = [{ 1, 2 }]; Nice, did´n knew that it worked. On Friday, 21 October 2016 at 21:41:16 UTC, Daniel Kozak wrote: Because there is no need. In c++ it is disaster because there is milion way how to initialize something, it is really hard to understand and inconsistent I never really felt lost about it with c++, but the argument holds true anyway :) There has been a abandoned proposal for struct initialization: https://github.com/dlang/DIPs/pull/22
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Saturday, 22 October 2016 at 22:05:54 UTC, Jonathan M Davis wrote: On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote: I'm ready to participate (but I can't invest too much time at the moment). Are we going with @rvalue ref? That would certainly be my preference - at least out of what's been discussed thus far. - Jonathan M Davis With move semantics in mind, I'm wondering if there may be a better word. Currently in D, IIRC, explicit moving can be done through by-value arguments. If you want to move explicitly from an lvalue, you can use D's std.move(lvalue). The downside is an extra blit/init into the rvalue that's returned by std.move. Then, the function that takes the rvalue may blit again in order to store the contents that are being moved in. As an alternative, non-const '@rvalue ref param' could be used...but would it be clear enough to people(seeing non-const @rvalue) that the contents of the argument could potentially be consumed/moved-from?
Re: Render SVG To Display And Update Periodically
On Saturday, 22 October 2016 at 06:18:13 UTC, Mike Parker wrote: I think I can confidently assure you that you aren't running into any bugs here. Thanks for the confirmation. It helps me to learn. You've dived right into a multi-module projects without a full understanding of imports and linking. I suggest you back up a bit and get familiar with the process before tackling ketmar and Adam's stuff. If they used dub, it would be a very easy process. Since they don't, and you have to manage it all manually, you need a solid understanding of how DMD handles this stuff and why you are getting the error messages you see. I'm used to compiling stuff in FreeBSD land. They have a group of people who take care to manage the build process (the dub part, i presume). What you say above is correct. I don't understand imports and linking. I can read the docs and they make sense, but I don't quite get it yet. Thanks for writing up that simple exercise. That's next. I was able to compile a working executable by specifying almost all *.d files on the command line. It didn't render an image, but it did pop up a window with an error message saying it couldn't load an image. I'm calling that victory. Regards, Jason
Re: Real Simple Question?
On Saturday, October 22, 2016 21:34:36 WhatMeWorry via Digitalmars-d-learn wrote: > Ok, but now I'm getting these error in my new > mypackage/constants.d > > ..\common\vertex_data.d(5,15): Error: undefined identifier > 'GLfloat' > ..\common\vertex_data.d(53,12): Error: undefined identifier 'vec3' mypackage/constants.d needs to import the modules for any of the types it's using, otherwise it doesn't know about them. Modules are not textually included like header files are in C++ (compilation times would be _way_ worse if they were), so a module only has access to what it imports, and it's not affected by anything that imports it. > Is there a way to just suck in the text from say a .txt file that > would not be compiled before inclusion in main.d? String imports is a feature, but then you end up with multiple copies of the array in your program instead of one, and string imports are almost always the wrong solution. - Jonathan M Davis
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote: > I'm ready to participate (but I can't invest too much time at the > moment). Are we going with @rvalue ref? That would certainly be my preference - at least out of what's been discussed thus far. - Jonathan M Davis
Re: Dustmite can't handle my memory segfault
On Friday, 21 October 2016 at 10:13:23 UTC, Nordlöw wrote: #!/usr/bin/env python3 import sys import pty stat = pty.spawn(sys.argv[1:]) if stat == 256: exit(42)# remap to 42 else: exit(stat) Assuming you want to remap 134 to 0 (success): #!/bin/bash cmd="$1" shift 2>/dev/null $cmd "$@" [ $? = 134 ] && exit 0 || exit 1
Re: Real Simple Question?
On Saturday, 22 October 2016 at 20:51:14 UTC, Jonathan M Davis wrote: On Saturday, October 22, 2016 20:35:27 WhatMeWorry via Digitalmars-d-learn wrote: [...] Just put it in a separate module and then import it. e.g. file: mypackage/constants.d == module mypackage.constants; GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . ]; == file: main.d == import mypackage.constants; void main() { auto v = vertices; } == Probably the key thing to remember is that when you compile your program, all of the modules that are part of your program rather than a separate library need to be compiled into it. Simply importing them isn't enough - though using either rdmd or dub make that easier. This is the official documentation's page on modules: http://dlang.org/spec/module.html This is the chapter from Al's book that covers modules: http://ddili.org/ders/d.en/modules.html And you'd almost certainly benefit from simply reading Ali's book as a whole: http://ddili.org/ders/d.en/index.html - Jonathan M Davis Ok, but now I'm getting these error in my new mypackage/constants.d ..\common\vertex_data.d(5,15): Error: undefined identifier 'GLfloat' ..\common\vertex_data.d(53,12): Error: undefined identifier 'vec3' Is there a way to just suck in the text from say a .txt file that would not be compiled before inclusion in main.d?
Re: D Uniform initialization {}
S[] s = [{ 1, 2 }]; Nice, did´n knew that it worked. On Friday, 21 October 2016 at 21:41:16 UTC, Daniel Kozak wrote: Because there is no need. In c++ it is disaster because there is milion way how to initialize something, it is really hard to understand and inconsistent I never really felt lost about it with c++, but the argument holds true anyway :)
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 22.10.2016 03:10, Andrei Alexandrescu wrote: On 10/21/16 5:39 PM, Timon Gehr wrote: On 21.10.2016 09:56, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Nice! Make sure it is orthogonal to const. :) It would be great if you participated. Such a DIP needs you. -- Andrei I'm ready to participate (but I can't invest too much time at the moment). Are we going with @rvalue ref?
Re: "for" statement issue
On 22.10.2016 17:53, Nick Treleaven wrote: [1,2,3].fold!{a, b => a + b}.writeln; Probably (a, b => a + b) could be legal. It is. (It means pass a and the lambda b => a + b.)
Re: Real Simple Question?
On Saturday, October 22, 2016 20:35:27 WhatMeWorry via Digitalmars-d-learn wrote: > This is probably so simple that there's no example anywhere. > > Basically, I've got a huge array definition (see below) which I > reuse over and over again in different projects. > > GLfloat[] vertices = > [ > // Positions // Texture Coords > -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, > 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, > . > (lots and lots of values) > . > > I'd like to place this one array into a separate file and just > include it with a one line statement in many projects. I'm > thinking mixins and/or imports but then if I knew how to do this, > I wouldn't be asking. > > Thanks in advance. Just put it in a separate module and then import it. e.g. file: mypackage/constants.d == module mypackage.constants; GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . ]; == file: main.d == import mypackage.constants; void main() { auto v = vertices; } == Probably the key thing to remember is that when you compile your program, all of the modules that are part of your program rather than a separate library need to be compiled into it. Simply importing them isn't enough - though using either rdmd or dub make that easier. This is the official documentation's page on modules: http://dlang.org/spec/module.html This is the chapter from Al's book that covers modules: http://ddili.org/ders/d.en/modules.html And you'd almost certainly benefit from simply reading Ali's book as a whole: http://ddili.org/ders/d.en/index.html - Jonathan M Davis
Real Simple Question?
This is probably so simple that there's no example anywhere. Basically, I've got a huge array definition (see below) which I reuse over and over again in different projects. GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . I'd like to place this one array into a separate file and just include it with a one line statement in many projects. I'm thinking mixins and/or imports but then if I knew how to do this, I wouldn't be asking. Thanks in advance.
An interesting conference
http://2017.programmingconference.org/track/programming-2017-papers#Call-for-Papers Has a fresh feeling and a broad charter. I suggest taking a look at their CfP and considering preparing a submission. Andrei
Re: getting started with web server - vibe.d dub giving link error
On Saturday, 22 October 2016 at 17:21:45 UTC, Karabuta wrote: On Saturday, 22 October 2016 at 14:50:14 UTC, aman wrote: I just started on vibe.d on fedora and the experience is not pretty getting hello-world running. Please help. Below are the details. [...] I wrote a blog post at https://aberba.gtihub.io which has Fedora users covered. But somehow GitHub pages is not working so you can find it here too https://github.com/aberba/aberba.github.io/blob/master/_posts/2016-08-20-hello-world-app-with-the-vibe.d-web-framework.md Sorry for the typo, blog link is rather https://aberba.github.io/#blog
Re: getting started with web server - vibe.d dub giving link error
On Saturday, 22 October 2016 at 14:50:14 UTC, aman wrote: I just started on vibe.d on fedora and the experience is not pretty getting hello-world running. Please help. Below are the details. [...] I wrote a blog post at https://aberba.gtihub.io which has Fedora users covered. But somehow GitHub pages is not working so you can find it here too https://github.com/aberba/aberba.github.io/blob/master/_posts/2016-08-20-hello-world-app-with-the-vibe.d-web-framework.md
Re: "for" statement issue
On 10/22/2016 05:53 PM, Nick Treleaven wrote: Probably (a, b => a + b) could be legal. Reasoning: 1. a could be an existing symbol in scope, otherwise it's an undefined identifier error. 2. If a was interpreted as an existing symbol which is followed by the comma operator, the expression (a) wouldn't have side effects so should be a compile error. How is it guaranteed that `a` doesn't have side effects? May be a function call, since empty parentheses can be omitted in calls. 3. The bracketed comma expression would have to return the lambda b=>a+b as a value expression, which cannot compile because there are no arguments supplied for calling the lambda to obtain a value. The lambda itself is a value, no? int a() { import std.stdio; writeln("a"); return 1; } void main() { int delegate(int) dg = (a, b => a + b); }
Re: "for" statement issue
On Friday, 21 October 2016 at 13:42:49 UTC, Adam D. Ruppe wrote: On Friday, 21 October 2016 at 13:33:26 UTC, Stefan Koch wrote: It does create a lambda? Hmm that should not happen. Eh, that's exactly what the language rules say should happen, and it actually does make sense to me... you might even want to use an immediately-called lambda to group several statements together into one expression. int j; for({j=2; int d = 3; } j+d<7; {j++; d++;}) { } I'm more surprised by the fact that `d` is declared inside the first curly braces, but is evidently still in scope outside of it...
[Issue 14831] Each function local symbols should have unique mangled name
https://issues.dlang.org/show_bug.cgi?id=14831 Vladimir Panteleevchanged: What|Removed |Added CC||acehr...@yahoo.com --- Comment #6 from Vladimir Panteleev --- *** Issue 16608 has been marked as a duplicate of this issue. *** --
[Issue 16608] 'static foreach', nested function template, 'static if', anySatisfy: Only the first iteration seems to work
https://issues.dlang.org/show_bug.cgi?id=16608 Vladimir Panteleevchanged: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #7 from Vladimir Panteleev --- *** This issue has been marked as a duplicate of issue 14831 *** --
[Issue 16608] 'static foreach', nested function template, 'static if', anySatisfy: Only the first iteration seems to work
https://issues.dlang.org/show_bug.cgi?id=16608 Mathias Langchanged: What|Removed |Added Status|NEW |RESOLVED CC||mathias.l...@sociomantic.co ||m Resolution|--- |DUPLICATE --- Comment #6 from Mathias Lang --- Yeah, sadly this is a known (and old bug), one of the worst IMO. The meta bug that Kenji opened to solve this is https://issues.dlang.org/show_bug.cgi?id=14831 *** This issue has been marked as a duplicate of issue 14381 *** --
[Issue 14381] It is too difficult to contribute to the auto-tester
https://issues.dlang.org/show_bug.cgi?id=14381 Mathias Langchanged: What|Removed |Added CC||acehr...@yahoo.com --- Comment #8 from Mathias Lang --- *** Issue 16608 has been marked as a duplicate of this issue. *** --
Re: Render SVG To Display And Update Periodically
Now I think I finally see where my hang up is. If B imports C, and A imports B and C, you still have to tell A where to find C. C doesn't go along for the ride with B. Stated another way, A doesn't look inside B to find C. Stated yet another way, B does not expose C to A. The statement above that I did not include nanovg.d on the command line finally clued me in. The statement that I was being "picky" about what to compile similarly helped. sh$> dmd $(find . -name "*.d") <== a joke, sort of. Eager to make the next try. Gotta run for a bit.
[Issue 16622] multiple scope(exit) are damaging the stack
https://issues.dlang.org/show_bug.cgi?id=16622 Mathias Langchanged: What|Removed |Added Status|NEW |RESOLVED CC||mathias.l...@sociomantic.co ||m Resolution|--- |WONTFIX --- Comment #3 from Mathias Lang --- The specs explicitly mention you shouldn't do that: > A scope(exit) or scope(success) statement may not exit with a throw, goto, > break, continue, or return; nor may it be entered with a goto. Ref: http://dlang.org/spec/statement.html#ScopeGuardStatement It might work in some situations though (happen to work on Linux). If you think it should always work feel free to bring it up on the N.G. or open an enhancement request with the rationale. --
[Issue 16532] Add "namespace" Keyword?
https://issues.dlang.org/show_bug.cgi?id=16532 Mathias Langchanged: What|Removed |Added CC||mathias.l...@sociomantic.co ||m --- Comment #4 from Mathias Lang --- > Really namespaces already exist in D, just they are very crudly implemented > by either meaning horrible to maintain with a bunch of extra module files or > through the use of structs. Adding namespaces would just be for sanity so > that code like above isn't possible and so that namespaces are treated as > such. As well adding namespace keyword will also help port from C++ if there > is any code that needs it. Just a thought for a small improvement. First, this is an enhancement proposal, thus it should go through the DIP process: https://github.com/dlang/DIPs/ Second, namespacing in D are supported through module / packages. You can choose to introduce extra namespacing without introducing new modules/packages by using aggregates as already mentioned, but it sounds like your real problem is trying to code with a C++ approach in D. --
Re: "for" statement issue
On Friday, 21 October 2016 at 15:26:12 UTC, mogu wrote: [1,2,3].fold!((a, b) => a + b).writeln; => [1,2,3].fold!{a, b => a + b}.writeln; Probably (a, b => a + b) could be legal. Reasoning: 1. a could be an existing symbol in scope, otherwise it's an undefined identifier error. 2. If a was interpreted as an existing symbol which is followed by the comma operator, the expression (a) wouldn't have side effects so should be a compile error. 3. The bracketed comma expression would have to return the lambda b=>a+b as a value expression, which cannot compile because there are no arguments supplied for calling the lambda to obtain a value. So this syntax seems available as it isn't currently used for working code. A small change, maybe, but it's good to reduce bracket nesting to help with reading complex nested expressions. Destroy.
Re: I can't use nodejs anymore. Please vibe.d, don't follow that path
On Friday, 21 October 2016 at 11:14:41 UTC, Sönke Ludwig wrote: Am 20.10.2016 um 22:25 schrieb Karabuta: This is actually a nodejs project's dependencies for a small code-base. (...) Dependencies upon dependencies. Each package comes along with its own dependencies. I give up nodejs, you win. Now I am investing my time in Vibe.d which I hope ... I personally always try to minimize external dependencies, because at some point they always cause problems. Sometimes it's possible to resolve those quickly, but even then, it usually leaves a bad taste if they are required for the whole system to function reliably. On the other hand, my plan is definitely to split vibe.d itself up into separate libraries, so that they can be maintained and versioned according to their individual development pace. But that means just that they are in separate repositories instead of submodules within the same one, not finer granularity. The thing about nodejs web frameworks is the usually lack of some basic functionality you would expect from say PHP without external libs. Little/single packages are more trouble, each with its own API design convention. Makes maintenance tedious. When one package dies out of support, problem comes: you have to find something else (which involves making huge code changes).
getting started with web server - vibe.d dub giving link error
I just started on vibe.d on fedora and the experience is not pretty getting hello-world running. Please help. Below are the details. setup the env via yum (I have installed ldc). dub init test -t vibe.d (go ahead with default options) cd test dub Performing "debug" build using ldc2 for x86_64. vibe-d:utils 0.7.29: target for configuration "library" is up to date. vibe-d:data 0.7.29: target for configuration "library" is up to date. vibe-d:core 0.7.29: target for configuration "libevent" is up to date. vibe-d:http 0.7.29: target for configuration "library" is up to date. vibe-d:diet 0.7.29: target for configuration "library" is up to date. vibe-d:mail 0.7.29: target for configuration "library" is up to date. vibe-d:mongodb 0.7.29: target for configuration "library" is up to date. vibe-d:redis 0.7.29: target for configuration "library" is up to date. vibe-d:web 0.7.29: target for configuration "library" is up to date. vibe-d 0.7.29: target for configuration "libevent" is up to date. test ~master: building configuration "application"... .dub/obj/app.o: In function `_D3std6digest3sha20__T3SHAVii512Vii160Z3SHA21_sharedStaticCtor3644FNbNiNfZv': /usr/include/d/std/digest/sha.d:224: undefined reference to `_D3std8internal6digest9sha_SSSE314transformSSSE3FNaNbNiPG5kPxG64hZv' ../.dub/packages/vibe-d-0.7.29/vibe-d/libvibe-d.a(vibe.vibe.o): In function `_D3std6digest3sha20__T3SHAVii512Vii160Z3SHA21_sharedStaticCtor3643FNbNiNfZv': /usr/include/d/std/digest/sha.d:224: undefined reference to `_D3std8internal6digest9sha_SSSE314transformSSSE3FNaNbNiPG5kPxG64hZv' ../.dub/packages/vibe-d-0.7.29/vibe-d/libvibe-d_redis.a(vibe.db.redis.sessionstore.o): In function `_D3std6digest3sha20__T3SHAVii512Vii160Z3SHA21_sharedStaticCtor3125FNbNiNfZv': /usr/include/d/std/digest/sha.d:224: undefined reference to `_D3std8internal6digest9sha_SSSE314transformSSSE3FNaNbNiPG5kPxG64hZv' ../.dub/packages/vibe-d-0.7.29/vibe-d/libvibe-d_web.a(vibe.web.common.o): In function `_D3std6digest3sha20__T3SHAVii512Vii160Z3SHA21_sharedStaticCtor3291FNbNiNfZv': /usr/include/d/std/digest/sha.d:224: undefined reference to `_D3std8internal6digest9sha_SSSE314transformSSSE3FNaNbNiPG5kPxG64hZv' ../.dub/packages/vibe-d-0.7.29/vibe-d/libvibe-d_diet.a(vibe.templ.utils.o): In function `_D3std6digest3sha20__T3SHAVii512Vii160Z3SHA21_sharedStaticCtor3140FNbNiNfZv': /usr/include/d/std/digest/sha.d:224: undefined reference to `_D3std8internal6digest9sha_SSSE314transformSSSE3FNaNbNiPG5kPxG64hZv' ../.dub/packages/vibe-d-0.7.29/vibe-d/libvibe-d_http.a(vibe.http.session.o):/usr/include/d/std/digest/sha.d:224: more undefined references to `_D3std8internal6digest9sha_SSSE314transformSSSE3FNaNbNiPG5kPxG64hZv' follow collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1
Re: Render SVG To Display And Update Periodically
On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells wrote: nanovg_demo>dmd example.d iv\arsd\color.d iv\arsd\simpledisplay.d iv\perf.d iv\perf.d(41): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be imported with 'import iv.nanovg.nanovg;' demo.d(6): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be imported with 'import iv.nanovg.nanovg;' iv/nanovg/nanovg does not exist in the source code zip files. (I was reluctant to duplicate nanonvg into iv\nanovg because somewhere I learned that copy-pasting code is a bad idea.) it's way easier, actually. first, you don't have to place files into correct directories if you are passing all of them (files) as arguments to dmd. they don't even have to have correct names. "correct" file placement is required only if dmd should search for modules on his own. second: you simply didn't pass all the required modules. perf.d depends on core nanovg engine, but you didn't passed that to dmd. the easiest way is just pall *all* *.d files you have to dmd. don't try to be picky ;-), dmd is fast enougth that you can safely pass alot of sources to it. and there is no harm in providing dmd with "extra" modules. as for "correct" placement (if you want it), it should be like that: dmd -Imodroot main.d main.d is your main D file, modroot is dir where all modules will be. it should be like that: modroot/arsd/color.d modroot/arsd/ modroot/iv/nanovg/nanovg.d modroot/iv/nanovg/ also, pref.d module is completely unnecessary, it is just utility thingy to show FPS counter. ;-) p.s. you will also need stb_ttf port, arsd repo has it under the name "ttf.d". p.p.s. the easiest way to do everything is this: mkdir modroot cd modroot git clone git://repo.or.cz/iv.d.git iv git clone https://github.com/adamdruppe/arsd.git arsd cd .. rdmd -Imodroot main.d ;-)
Re: Reflection: Order of fields guaranteed?
On Friday, 21 October 2016 at 01:51:44 UTC, Stefan Koch wrote: On Friday, 21 October 2016 at 01:34:44 UTC, Nick Sabalausky wrote: When using reflection to obtain the fields of a class/struct, is there any guarantee that the order is the same as the order the fields are defined? Yes they should always come in lexical order. For classes, the spec disagrees, even though it might be true using current compilers. https://dlang.org/spec/class.html#fields "The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. ... Explicit control of field layout is provided by struct/union types, not classes."
Re: Why are homepage examples too complicated?
On Friday, 21 October 2016 at 23:08:06 UTC, Benjiro wrote: On Thursday, 20 October 2016 at 09:10:10 UTC, Chris wrote: O, that webshop that now needs a rewrite from zero, was a direct result of another outsource. Yay! And the client ends up paying ( again ) for that. Some things never change... Unfortunately, bosses are bosses. Two senior PHP developers cost money ( hell, we are cheap, under payed ). They can never stop looking for money, while they trow money out of the door in one after another foolish scheme. Technically we are keeping the company afloat. *sigh* Some things never change...:) The real craftsmanship behind a website is mastering the various technologies that don't work smoothly together (HTML, JS, PHP, forms, requests, server side stuff, browsers, data bases). Web design is 90% page logic, 10% inspiration. On this i kind of disagree. I can handle all the web techs with ease but you need people who can see things more in graphical / marketing / ease of use sense. We developers see a lot of times too much from our perspective. I meant that the design can be fixed fast after having been tested by users. It's not rocket science. A lot of it is common sense, but design is what everybody sees, so it makes a bigger impression on the marketing section. They don't care for the lean data base design you might be proud of, they want a shiney button that says "Book now" :) Its the same reason why i mentioned the whole examples on the front page. While i had more then one reason to skip D, the mentioned example was one of them. When people have choices, they make them very fast. Ali for instance, did a great job on his book. Its easy to get into, maybe a bit redundant from a more experience developers point of view but you quickly see the small details. Things you will simply look over without realizing. Stupid and simple example that will make every developer here think: "this Benjiro guy is stupid". *haha* The thing is that it takes time to learn a language like D and get used to its idioms. And as has been pointed out, different newbies have different expectations. What you could do for D, if you wish, you could draw up a syntax cheat sheet with one-line examples. 1. String concatenation `~` // writeln("Hello, " ~ "world!"); 2. Array concatenation ... 3. Assoc array syntax ... etc. I sometimes too get stuck on little things like that when I have to work with a language I'm not familiar with ("." or "+" or ...) Don't ask what D can do for you, but what you can do for D. I ripped that one :)
Re: Phobos lacks a particular family of range functions...
On Friday, 21 October 2016 at 19:41:00 UTC, Basile B. wrote: They would have for constraint `if (isInputRange!Range && isInputRange!(ElementType!Range))` In case you wouldn't see directly what would they be used for, it's for tree-like structures. Each element in a Range is also an input range. I see 3 obvious functions/templates - the most important, make an input range from a tree-like range, e.g `auto treeRange(Range, DepthMode mode)(Range range) ` - a second version for bidir ranges, e.g `reverseTreeRange` - a functional iteration algorithm: auto `deepIterate(alias Fun, DepthMode mode, Range, A...)(Range range, auto ref A a)`, which applies Fun to each element with the ability for Fun to act as a predicates to stop the iteration. Actually I have this one in my user library (this is also the reason why I post this today). Unless I'm blind I cannot see anything that handles trees with a range interface in phobos. If you want to get the spirit see: https://github.com/BBasile/iz/blob/master/import/iz/sugar.d#L1214 Now a few hours later I wonder if it could be a ndSlice job ? I haven't used it so far, so I ask.
Re: rt_init, rt_term and _initCount
On Saturday, 22 October 2016 at 07:12:48 UTC, Rainer Schuetze wrote: Please also consider that the main executable might not know about DLLs being written in D. In that case all termination must be triggered by the druntime DLL. The case where the main executable is not D is working fine. The problem at the moment is the case where the main executable is D. So I will be going for the dll registration approach then. As you said we can add in the thread join in case it becomes a problem.
Re: New to D
On Saturday, 22 October 2016 at 08:05:12 UTC, Daniel Kozak wrote: uint[string] dictionary; should be uint[size_t] dictionary; because size_t is 32bit on x86 system and 64bit on x86_64 and you are trying to put array length to dictionary which is size_t I believe you meant: size_t[string];
Re: New to D
Dne 22.10.2016 v 07:41 Mark via Digitalmars-d-learn napsal(a): Thanks for the fast reply. That did work. But now the error is on the line: dictionary[word] = newId; I changed the value to 10, still errors. ?? everything else is as before. thanks. uint[string] dictionary; should be uint[size_t] dictionary; because size_t is 32bit on x86 system and 64bit on x86_64 and you are trying to put array length to dictionary which is size_t
Re: rt_init, rt_term and _initCount
On 22.10.2016 01:21, Benjamin Thaut wrote: On Friday, 21 October 2016 at 19:40:52 UTC, Rainer Schuetze wrote: The wrapper around main in the executable should work just as any DLLs' DllMain, i.e. it should register/unregister its own data segments with the GC and run its shared and TLS module constructors/decoontructors. Everything else should be handled by the druntime DLL. Yes, I also considered that option. The problem with that is, that druntime deinit joins alls threads before running the shared module dtors. If the main executable behaves exactly like the dlls do this joining of threads would be lost and different from the behavior of a fully statical linked executable. The main executable wrapper could add this join-all if it is considered useful. I'm not really convinced: If there are actually threads still running on program termination, it's likely they need some signal to stop. In C++ that is usually fired in the shared destructor of some global. This is currently not possible in D as these are run after joinAll. Please also consider that the main executable might not know about DLLs being written in D. In that case all termination must be triggered by the druntime DLL.
Re: Render SVG To Display And Update Periodically
On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells wrote: First, thank you for taking the time to help me with something that should be trivial. I've done the above listing of file on the command line but I'm still stuck. I'm starting to think that I might actually be tripping over bugs, but I'm not confident enough to believe that without some confirmation. I think I can confidently assure you that you aren't running into any bugs here. I have the following directory structure from the zipfiles found in the repositories posted by ketmar. nanovg_demo - iv (was renamed from nanovg based on dmd error messages) -- arsd (was renamed from arsd-master based on dmd error messages) To proceed, I would attempt a compile. Then I would add the file that was producing an error to the command line and try again. I got this far. Via cmd.exe: nanovg_demo>dmd example.d iv\arsd\color.d iv\arsd\simpledisplay.d iv\perf.d iv\perf.d(41): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be imported with 'import iv.nanovg.nanovg;' demo.d(6): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be imported with 'import iv.nanovg.nanovg;' iv/nanovg/nanovg does not exist in the source code zip files. (I was reluctant to duplicate nanonvg into iv\nanovg because somewhere I learned that copy-pasting code is a bad idea.) looking at kemar's repository, the nanovg.d module belongs to the iv.nanovg package. I don't know what the zip directory tree looks like, but you should have this: - iv -- nanovg --- fui --- nanovg.d --- oui --- package.d --- perf.d --- svg.d As for the asrd stuff, it shouldn't bee in the iv tree at all. You should do something like this: - import -- iv -- arsd Both iv and arsd are top-level packages, so they ought to be independent of each other. demo.d(7): Error: module oui is in file 'iv\nanovg\oui.d' which cannot be read oui.d does not exist anywhere. There is, however, a oui directory. If you look at the source for demo.d, you'll see that it makes use of the oui package. That means the everything there also needs to be compiled and linked into the binary, but you haven't given those files to the compiler. As a side note, I did have some success. I am able to compile nanovg.lib quite easily (from tips provided a few messages ago). It's when I try to compile the demo that I get stuck. Which files did you add into nanovg.lib? Everything in the iv.nanovg packages and subpackages, or just the ones you use directly? It's best to compile all of them into the lib, then any that are used indirectly by each other are also available. You've dived right into a multi-module projects without a full understanding of imports and linking. I suggest you back up a bit and get familiar with the process before tackling ketmar and Adam's stuff. If they used dub, it would be a very easy process. Since they don't, and you have to manage it all manually, you need a solid understanding of how DMD handles this stuff and why you are getting the error messages you see. Try playing around with simple single-function modules, starting with something like this: io.d: ``` void print(string s) { import std.stdio : writeln; writeln(s); } ``` main.d: ``` import io; void main() { print("Hello, D!"); } ``` Compile both: dmd main.d io.d Compile separately: dmd -c io.d dmd main.d io.obj Move the io.d module into a package, mylib.io: - main.d -- mylib --- io.d Add a module statement to the top of io.d: ``` module mylib.io; ``` Change the import in main.d: ``` import mylib.io; ``` Try again compiling together, then separately. Then move the mylib directory: - main.d -- lib --- mylib io.d Then compile together and separately again. Try with and without -Ilib in both cases and see what happens. Add another single-function module into the mix. Compile mylib as a library and try again. Just keep experimenting like this until you've worked out exactly what's going on and what the error messages mean. Then you can tackle the naonvg and arsd.