Re: DUB 0.9.22 released
On 22/09/14 23:04, tn wrote: What is the recommended way of versioning bindings? If the binding of the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the binding (no change in the target library), how should the new version of the binding for target version 1.2.3 be versioned? Using 1.2.4 is not an option because it potentially collides with the binding for the next version of the target. The problem is locking the version of the Dub package to the same version of the library the bindings are for. In you're example I would do something like 1.2.3+1.2.3. If you need fix a bug in the bindings you increment as usual to 1.2.4+1.2.3. Anything after the plus sign is basically metadata that is ignore by Dub -- /Jacob Carlborg
Re: DUB 0.9.22 released
Am 23.09.2014 03:50, schrieb K.K.: This inclusion into the DMD install, is just that DMD comes with the dub.exe and .dll's (and ofcourse the linux mac equivalents) in it's folders, correct? Yes, that's it basically.
Re: DUB 0.9.22 released
On Tuesday, 23 September 2014 at 06:22:27 UTC, Jacob Carlborg wrote: On 22/09/14 23:04, tn wrote: What is the recommended way of versioning bindings? If the binding of the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the binding (no change in the target library), how should the new version of the binding for target version 1.2.3 be versioned? Using 1.2.4 is not an option because it potentially collides with the binding for the next version of the target. The problem is locking the version of the Dub package to the same version of the library the bindings are for. In you're example I would do something like 1.2.3+1.2.3. If you need fix a bug in the bindings you increment as usual to 1.2.4+1.2.3. Anything after the plus sign is basically metadata that is ignore by Dub In your suggestion, once version 1.2.4 of the target library is released, the first binding version targeting that would then be 1.2.4+1.2.4 or 1.2.5+1.2.4 or what? And more importantly, how can a user of the binding then depend on the latest binding version of a specific target library version (for example the latest bindings for 1.2.3)?
Re: Digger 1.0
On 22/09/2014 19:59, Vladimir Panteleev wrote: Firefox requires 4GB of memory to build. Chromium requires 8GB of memory to build. Android requires 16GB of memory to build. Thanks for the info, I didn't realize. If you want to work on big projects, you WILL need a decent computer. I think 4GB for a modern programming language's implementation is not an unreasonable requirement, even if it could be brought down in the future. Especially considering that you can't even buy a new laptop today with less than 4GB of RAM, and 3GB is becoming the norm for smartphones. OK. Perhaps I can upgrade my RAM (I can't afford a new computer). Linking phobos.lib is the first time I've got OOM, I use Firefox heavily. phobos.lib is only 10 MB, which is why I thought it odd that linking uses well over 1 GB.
Mono-D v2.4.9 - Parser fixes
Hi everyone, just wanted to announce a further small version bump of Mono-D. And yeah, despite my 2 week-break, development still continues! Cheers, Alex
Re: Mono-D v2.4.9 - Parser fixes
On Tuesday, 23 September 2014 at 14:02:47 UTC, Alexander Bothe wrote: Hi everyone, just wanted to announce a further small version bump of Mono-D. And yeah, despite my 2 week-break, development still continues! Cheers, Alex Durr, forgot to put in links: Release notes: http://wiki.dlang.org/Mono-D_Release_Notes Wiki: http://wiki.dlang.org/Mono-D Github: https://github.com/aBothe/D_Parser / https://github.com/aBothe/Mono-D
Re: Digger 1.0
On Monday, 22 September 2014 at 13:23:33 UTC, simendsjo wrote: My guess is the average for developers is ~8GB. 2GB RAM is really not enough for pretty much anything these days - the browser alone easily chews 3-4GB on moderate use. You have to admit that this is ridiculous. I updated to the 64-bit Chrome on Windows when it came out and it is a huge memory hog. Web browsers have grown out of control. On Monday, 22 September 2014 at 18:59:13 UTC, Vladimir Panteleev wrote: Firefox requires 4GB of memory to build. Chromium requires 8GB of memory to build. This is not a requirement for Chromium, merely a recommendation for faster builds. I regularly built Chromium for FreeBSD with 2 GBs of RAM up till a couple years ago. Perhaps it has gotten much more bloated since or maybe just on Windows, but phobos shouldn't be in the same class. If you want to work on big projects, you WILL need a decent computer. I think 4GB for a modern programming language's implementation is not an unreasonable requirement, even if it could be brought down in the future. Especially considering that you can't even buy a new laptop today with less than 4GB of RAM, and 3GB is becoming the norm for smartphones. I'd say it's unreasonable from a technical standpoint, maybe not that much from an affordability standpoint, which is what you're pointing out. My guess is the real problem is optlink on Windows, in which case I recommend that Nick try out the new 32-bit MSVC toolchain support, if he can't use the existing 64-bit Windows MSVC integration. I regularly build git HEAD of dmd/druntime/phobos in a linux VM with 512 MB of RAM and about the same amount of swap and have never had a problem. It's only when compiling the unit tests that I have to start increasing the allocated RAM.
Re: Digger 1.0
On Saturday, 20 September 2014 at 20:07:46 UTC, Vladimir Panteleev wrote: Yet another release ruined by a DMD -inline wrong-code bug :( It seems like use of -inline is not recommended then?
[OT] Memory usage and Web (WAS: Re: Digger 1.0)
On 09/23/2014 04:48 PM, Joakim wrote: On Monday, 22 September 2014 at 13:23:33 UTC, simendsjo wrote: My guess is the average for developers is ~8GB. 2GB RAM is really not enough for pretty much anything these days - the browser alone easily chews 3-4GB on moderate use. You have to admit that this is ridiculous. I updated to the 64-bit Chrome on Windows when it came out and it is a huge memory hog. Web browsers have grown out of control. It's well beyond rediculous. After I log into my graphical environment with everything started, ~200MB is used. Launch a browser, and suddenly ~3800MB is used. If it wasn't for everyone hailing the inner platform effect (usually seen as a bad thing) as the best thing since sliced bread, many laptops would probably not ship with 4GB standard. But if your parents want Facebook and Instagram, you better give them a pretty beefy computer. Oh... And the CPU requirements is pretty steep too - even my Lenovo T520 (Core i7) is really slow at browsing the web! Oh.. And did I forget? You have to run a dynamic programming language that pushes most mistakes easily caught at compile-time to runtime errors. I obviously don't think The Web™ has made the right choices. The amount of Javascript hype I see makes me quite ill. An OS? Really? In Javascript? Seriously?
Re: DUB 0.9.22 released
Arch Linux package has been updated. Does not include auto-completion right now, will do a point release with it soon-ish
Re: Mono-D v2.4.9 - Parser fixes
On 9/23/14, 7:06 AM, Alexander Bothe wrote: On Tuesday, 23 September 2014 at 14:02:47 UTC, Alexander Bothe wrote: Hi everyone, just wanted to announce a further small version bump of Mono-D. And yeah, despite my 2 week-break, development still continues! Cheers, Alex Durr, forgot to put in links: Release notes: http://wiki.dlang.org/Mono-D_Release_Notes Wiki: http://wiki.dlang.org/Mono-D Github: https://github.com/aBothe/D_Parser / https://github.com/aBothe/Mono-D Awesome! I'm using it on OSX, works nice. -- Andrei
Re: [OT] Memory usage and Web (WAS: Re: Digger 1.0)
On Tue, 23 Sep 2014 18:29:17 +0200 simendsjo via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: But if your parents want Facebook and Instagram, you better give them a pretty beefy computer. i'll give 'em opera 12. yes, it's dead, but it's the only browser that can work month by month without restarting (no, i'm not kidding!) and feel itself good in ~300-400 MB of RAM. no FOSS bloatware browser can compete (alas). signature.asc Description: PGP signature
native ZMBV video codec
Hello. last night i ported ZMBV video codec to D. ZMBV is videocodec invented by DosBox team to record old videogames' gameplay. if you are into writing old-school games, it can be handy to embed the possibility to creating gameplay video directly in your game. it's only codec for now (i.e. it can't write .avi files, only encoding and decoding raw frame data). it's a port of GPLv3 code, so it is GPLv3 too, sorry. documentation is non-existent for now, but i'm planning to add some samples along with .avi writer. codec is using libc malloc()/realloc()/free() for it's internal data (and tries not to allocate things very often). yet it throws alot of exceptions on invalid input or output, so beware. sorry for shitty code, it's a port of a port of a port, and it was made in a hurry. here is the source: http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/zmbv.d p.s. don't bother to pull other modules from the repo: they either not finished/polished or not written in 'standard D' anyway. signature.asc Description: PGP signature
Re: DUB 0.9.22 released
On 2014-09-23 10:08, tn wrote: In your suggestion, once version 1.2.4 of the target library is released, the first binding version targeting that would then be 1.2.4+1.2.4 or 1.2.5+1.2.4 or what? If the previous binding version was 1.2.3+1.2.3 the next would be 1.2.4+1.2.4. Just increment as usual. It could also be that the target library doesn't follow Semver and if it contains an API breaking change it would be 2.0.0+1.2.4. And more importantly, how can a user of the binding then depend on the latest binding version of a specific target library version (for example the latest bindings for 1.2.3)? Hmm, that's tricky. I don't have a good solution for that. It's easy to see if you look at all the versions. Just pick the highest version with the matching version after the plus. -- /Jacob Carlborg
Re: OpenSimplex Noise ported to D
On Tuesday, 23 September 2014 at 12:31:12 UTC, MrSmith wrote: On Sunday, 21 September 2014 at 02:36:46 UTC, Brian Schott wrote: Some of you may have noticed this article posted to /r/programming: http://uniblock.tumblr.com/post/97868843242/noise. I ported the algorithm to D and uploaded it here: https://github.com/Hackerpilot/OpenSimplexNoise-D Can you also make 2D version, please? You can get 2d noise from this by generating a slice of 3d noise. Call OpenSimplexNoise.eval(x, y, c) where x and y are loop variables and c is a constant. The test file[1] does this to produce a 2d image. [1] https://github.com/Hackerpilot/OpenSimplexNoise-D/blob/master/test/main.d
Re: Mono-D v2.4.9 - Parser fixes
Already read it on Twitter - nice to hear this! :) On Tuesday, 23 September 2014 at 16:53:23 UTC, Andrei Alexandrescu wrote: Awesome! I'm using it on OSX, works nice. -- Andrei
Re: OpenSimplex Noise ported to D
On Tuesday, 23 September 2014 at 12:31:12 UTC, MrSmith wrote: On Sunday, 21 September 2014 at 02:36:46 UTC, Brian Schott wrote: Some of you may have noticed this article posted to /r/programming: http://uniblock.tumblr.com/post/97868843242/noise. I ported the algorithm to D and uploaded it here: https://github.com/Hackerpilot/OpenSimplexNoise-D Can you also make 2D version, please? Hey, I'm the original creator of the algorithm. Found this thread in a Google search :P. I am planning on releasing both 2D and 4D variants of this algorithm. The 4D variant is mostly done, and the 2D should take practically no time at all afterwards. But if you need 2D noise and you're not pinching for performance, just take a 2D slice of 3D noise by making one of the variables a constant. To me, doing that creates a more isotropic appearance than simply using 2D noise.
