Re: GCs are complicated beasts: .NET Core, 35000 lines
On 2/4/15 4:09 AM, Russel Winder via Digitalmars-d wrote: BTW The Go team have completely rewritten the Go GC 1.4 → 1.5. Of course they have also completely rewritten the entire Go toolchain. Compiler, linker, runtime all written in Go now, no more C. How does the rewrite compare against the originals? -- Andrei
Re: DIP56 - inlining
On 2/4/15 4:08 AM, Walter Bright wrote: On 2/4/2015 3:08 AM, Johannes Pfau wrote: The compiler will still have to generate a complete function which takes up space in the object file. Space in the object file is not important Yah, just within reason etc. etc. -- Andrei
Re: Module for manual memory management
For what it's worth, today I finished the current work. Now we will start working with it. If someone has critique, improvement suggestions or want to take some ideas, he is free to do so. To repeat myself: we rewrote some functionality which already existed in D, but were improvable. For example the existing emplace method is quite long, hard to understand / read and is not marked with @nogc. Since we want to avoid the GC wherever possible we had to rewrite it. I hope it's useful for someone else and that some of you guys take some ideas from it. https://github.com/Dgame/m3
Re: H1 2015 - db access support in Phobos
On 2/1/15 8:00 PM, Vadim Lopatin wrote: I would like to propose Java way for implementation of DB access (JDBC - Java DataBase Connectors). [snip] I think we should use ODBC as the foundation and build neat D-ish stuff on top of it. It's a mature technology with tried and tested drivers available on all major OSs. Mark Isaacson built an ODBC driver for Presto in D while an intern at Facebook: https://github.com/prestodb/presto-odbc. We should write the corresponding ODBC client part and create D abstractions on top of it. Andrei
Re: cast a C char array - offset ?
On Wed, 04 Feb 2015 16:09:24 +, irtcupc wrote: Thx again for your help Ketmar and FG, Thx again for the help in the other Q too (the one about snn imports), I share the binding, it's nothing at all but was a fun to do on a off-day... https://github.com/BBasile/dbeaengine you may want to add it to dub repo and announce in D.announce. don't think that D.announce is only for big projects, everyone is welcome. ;-) signature.asc Description: PGP signature
Re: cast a C char array - offset ?
On Monday, 2 February 2015 at 13:40:30 UTC, irtcupc wrote:
On Monday, 2 February 2015 at 13:34:28 UTC, ketmar wrote:
On Mon, 02 Feb 2015 13:32:57 +, ketmar wrote:
On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw
chunk - D:
defining the member as char[INSTRUCT_LENGTH] is an error -
the first
member of a D array is the .length - first char actually
stands where
.length uses to be, which explains the shift.
nope. fixed length arrays doesn't have dedicated `.length`
member. try
this:
align(1)
struct _Disasm {
align(1):
...
actually, first align is not necessary at all. i.e.:
struct _Disasm {
align(1):
the difference is that `align` before struct tells how
structure should
be packed (i.e. when you have `_Disasm[2] arr`). and `align`
*inside*
struct tells compiler how struct *members* should be packed.
Thx, problem fixed, it works now.
Thx again for your help Ketmar and FG, Thx again for the help in
the other Q too (the one about snn imports), I share the binding,
it's nothing at all but was a fun to do on a off-day...
https://github.com/BBasile/dbeaengine
[Issue 13320] Redundant error messages for missing operation on struct instance
https://issues.dlang.org/show_bug.cgi?id=13320 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86 |All OS|Windows |All --
[Issue 13320] Redundant error messages for missing operation on struct instance
https://issues.dlang.org/show_bug.cgi?id=13320 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4381 --
Re: DIP56 - inlining
On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei
Re: Creating named tempfiles
On Wednesday, February 04, 2015 19:51:38 Daniel Murphy via Digitalmars-d wrote: Jonathan M Davis via Digitalmars-d wrote in message news:mailman.5879.1423038837.9932.digitalmar...@puremagic.com... Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions. Try extern(C) and see if it works. If it's a C function, it will most likely be using C mangling instead of system mangling. Yes. extern(C) does seem to do the trick. Thanks for guys' help. I've had the code sitting around incomplete for quite some time now, and it's long past time for it to become a PR. https://github.com/D-Programming-Language/phobos/pull/2956 - Jonathan M Davis
Re: Creating named tempfiles
On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote: You got it declared with stdcall convention, should change to cdecl. Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions. - Jonathan M Davis
Re: Creating named tempfiles
On Wednesday, February 04, 2015 09:02:01 ketmar via Digitalmars-d wrote: On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote: You got it declared with stdcall convention, should change to cdecl. Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions. for the most time `extern(Windows)` is using only for winapi calls. and `wsopen` is a library call, so it's likely an `extern(C)`. Well, unfortunately, a C function is a C function to me. I know that different calling conventions exist in Windows, but I have no idea why, what the difference is, or what they affect. AFAIK, it's not an issue that exists on POSIX systems. I really should study up on it. - Jonathan M Davis
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. I changed the description to: If a pragma specifies always inline, and the compiler cannot inline it, a warning will be generated. Implementations will likely vary in their ability to inline. I like it. This feels better than the C++ force_inline attribute solution. Would pragma(inline, bool-expr) be supported though? This would allow to pass inlining as a template parameter (can be useful to force recursive inlining, or to force inlining depending on the call point).
Re: 2D game engine written in D is in progress
Also do somebody know how should I speed up the sprite part of the code? In my opinion, it's pretty slow alrought it was the easiest way I could come up with. Hi, you have wrong approach to this problem. From design OOP view it is perfectly ok and this is how you universities teach it in their SQL classes... But you probably don't aim for clean OOP design but for speed. You work with every single sprite as entity. But you should aim to process sprites in batch. Your sprite should be probably struct, then feed array of them into separate function instead of calling on every sprite. Difference: foreach(sprite) sprite-doSth(); vs: doSth(sprite[]); this is good read: http://gameprogrammingpatterns.com/flyweight.html
Re: Record separator is being lost after string cast
Looks like RS is an unprintable character, that's why you don't see it in console.
Re: Creating named tempfiles
Jonathan M Davis via Digitalmars-d wrote in message news:mailman.5880.1423039515.9932.digitalmar...@puremagic.com... No, on further reflection, that can't be it, because it shows up in snn.lib, not just io.h. So, it's actually in the compiled library. So, it probably is a problem with the D declaration itself - be it the calling convention or something else. Yes, it's the calling convention.
Re: Creating named tempfiles
Jonathan M Davis via Digitalmars-d wrote in message news:mailman.5879.1423038837.9932.digitalmar...@puremagic.com... Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions. Try extern(C) and see if it works. If it's a C function, it will most likely be using C mangling instead of system mangling.
[Issue 14090] [REG2.067a] Incorrect recursive alias declaration
https://issues.dlang.org/show_bug.cgi?id=14090 --- Comment #3 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/16a0faab3d103e62f41bc29bd13add98ec6754a8 fix Issue 14090 - Incorrect recursive alias declaration https://github.com/D-Programming-Language/dmd/commit/06b656ae8d755b8f5aa3c451eee7f7cbd3f63e6d Merge pull request #4370 from 9rnsr/fix14090 Issue 14090 - [REG2.067a] Incorrect recursive alias declaration --
Re: Git, the D package manager
On Wed, 04 Feb 2015 09:26:37 +, eles wrote:
On Wednesday, 4 February 2015 at 05:35:44 UTC, ketmar wrote:
On Tue, 03 Feb 2015 17:33:53 +, Russel Winder via Digitalmars-d
wrote:
in no way ready for public usage.
In the context of this discussion, if you can spare 5 or 10 minutes, it
could be useful if you could provide a more detalied description of the
tool and the constraints/choices that you had to do.
actually, i'm using a heavily modified fork of jam[1]. i don't want to
advertise it, though, 'cause it's very ketmar-specific, and i have no
plans to make it usable for anyone who has some different views on build
process. ;-)
I kinda was always looking for the perfect build system and messed with
make, cmake, scons, waf, fbuild (https://github.com/felix-lang/fbuild),
boost.build, biicode etc.
Yes, not much ant, maven or gradle.
you can look at it here[2], but beware! it's not very well documented,
it's incompatible with any other jam fork out here, and it doesn't
contain ALL changes. ;-)
i was looking for good build system too, and jam was the one that
*almost* fits my needs at the time. then i started to fix some things
there, adding some things, and so on. i was never trying to write yet
another universal build system for anyone, it's just a tool for me and
my friends (yes, it actually has other users except me! ;-).
i dropped windows support some time ago (just don't need that, 'cause i'm
doing cross-compiles from GNU/Linux anyway) and added 'k8jam config'
supporting scripts, which does some checks that 'configure' does. it may
work on non GNU/Linux OSes, but i never check that ('cause i don't need
that ;-).
[1] http://en.wikipedia.org/wiki/Perforce_Jam
[2] http://repo.or.cz/w/k8jam.git
signature.asc
Description: PGP signature
Record separator is being lost after string cast
I am opening a .gz file and reading it chunk by chunk for
uncompressing it.
The data in the uncompressed file is like : aRSbRScRSd, There are
record separators(ASCII code 30) between each record(records in
my dummy example a,b,c).
File file = File(mylog.gz, r);
auto uc = new UnCompress();
foreach (ubyte[] curChunk; file.byChunk(4096*1024))
{
auto uncompressed = cast(string)uc.uncompress(curChunk);
writeln(uncompressed);
auto stringRange = uncompressed.splitLines();
foreach (string line; stringRange)
{
* Do something with line
The result of the code above is: abcd unfortunately record
separators(ASCII 30) are missing.
I realized by examining the data record separators are missing
after I cast ubyte[] to string.
Now I have two questions :
Urgent one (my boss already a little disturbed I started the task
with D I need to solve this): What should I change in the code to
keep record separator?
Second one : How can I write the code above without for loops? I
want to read gz file line by line.
A more general and understandable code for first question :
ubyte[] temp = [ 65, 30, 66, 30, 67];
writeln(temp);
string tempStr = cast(string) temp;
writeln (tempStr);
Result is : ABC which is not desired.
Thanks
Kadir Erdem
Re: H1 2015 Priorities and Bare-Metal Programming
On 3 February 2015 at 11:15, Iain Buclaw ibuc...@gdcproject.org wrote: On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2/2/2015 8:36 PM, Daniel Murphy wrote: If so, what corrective action is the user faced with: The user can modify the code to allow it to be inlined. There are a huge number of constructs that cause dmd's inliner to completely give up. If a function _must_ be inlined, the compiler needs to give an error if it fails. I'd like to reexamine those assumptions, and do a little rewinding. The compiler offers a -inline switch, which will inline everything it can. Performance oriented code will use that switch. So why doesn't the compiler inline everything anyway? Because there's a downside - it can make code difficult to symbolically debug, and it makes for difficulties in getting good profile data. Manu was having a problem, though. He wanted inlining turned off globally so he could debug his code, but have it left on for a few functions where not inlining them would make the debug version too slow. pragma(inline,true) tells the compiler that this function is 'hot', and pragma(inline, false) that this function is 'cold'. Knowing the hot and cold paths enables the optimizer to do a better job. There are literally thousands of optimizations applied. Plucking exactly one out and elevating it to a do-or-die status, ignoring the other 999, is a false god. There's far more to a programmer reorganizing his code to make it run faster than just sprinkling it with forceinline pixie dust. There is a lot of value to telling the compiler where the hot and cold parts are, because those cannot be statically determined. But exactly how to achieve that goal really should be left up to the compiler implementer. Doing a better or worse job of that is a quality of implementation issue, not a language specification issue. Perhaps the fault here is calling it pragma(inline,true). Perhaps if it was pragma(hot) and pragma(cold) instead? pragma(hot/cold) or @attribute(hot/cold) This maps well in gdc's framework too. Also 'flatten' - which allows you to control inlining at the caller, rather than the callee.
Re: Git, the D package manager
I would warn against this attitude. Trying to do too much magic is one of reasons I ignore all of modern build tools and still keep my makefiles. There is huge benefit in knowing that your build tool can express any dependency tree based workflow in uniform manner - be it compiling sometithing, downloading remote artifacts or generating a package. They're not mutually exclusive. High-level convenience can happily coexist with low-level control. Isn't that why we're on this forum? ;) Once more, CMake handles this well, modulo the terrible language to do it in. With a good base smart solutions can be built on top. This is actually how we use make in Sociomantic - by having a set of standard makefiles with D-specific rules that allow to define build target as simple as this: $B/appname: $C/src/appname/main.d all += $B/appname (yes, that is all that needs to be in actual makefile) That's pretty cool. I'm aiming for something along those lines. Atila
Re: Git, the D package manager
On Wednesday, 4 February 2015 at 05:35:44 UTC, ketmar wrote: On Tue, 03 Feb 2015 17:33:53 +, Russel Winder via Digitalmars-d wrote: in no way ready for public usage. In the context of this discussion, if you can spare 5 or 10 minutes, it could be useful if you could provide a more detalied description of the tool and the constraints/choices that you had to do. I kinda was always looking for the perfect build system and messed with make, cmake, scons, waf, fbuild (https://github.com/felix-lang/fbuild), boost.build, biicode etc. Yes, not much ant, maven or gradle.
Re: Record separator is being lost after string cast
don't beleive what you see! ;-)
I am sorry make a busy community more busy with false alarms.
When I write to file I saw Record Separator really exists.
I hope my second question is a valid one.
How can I write the code below better? How can I reduce the
number of foreach? statements.
File file = File(mylog.gz, r);
auto uc = new UnCompress();
foreach (ubyte[] curChunk; file.byChunk(4096*1024))
{
auto uncompressed = cast(string)uc.uncompress(curChunk);
writeln(uncompressed);
auto stringRange = uncompressed.splitLines();
foreach (string line; stringRange)
{
Thanks a lot for replies
Kadir Erdem
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Wait... That used to be told about C++, not about D...
Re: Creating named tempfiles
You got it declared with stdcall convention, should change to cdecl.
Re: Creating named tempfiles
On Wednesday, February 04, 2015 09:33:22 ketmar via Digitalmars-d wrote: On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d wrote: for the most time `extern(Windows)` is using only for winapi calls. and `wsopen` is a library call, so it's likely an `extern(C)`. Well, unfortunately, a C function is a C function to me. I know that different calling conventions exist in Windows, but I have no idea why, what the difference is, or what they affect. AFAIK, it's not an issue that exists on POSIX systems. I really should study up on it. it's mostly historical artifacts. and it's too late to change that. most of the time it's used to make your program crash in most unexpected ways. first windows was written in pascal, so it has pascal calling convention (left-to-right order, callee cleans the stack). i don't know why, but when they go to 32-bit version, they start using stdcall calling convention (right-to-left order, yet callee still cleans the stack). that is what `extern(Windows)` in D means. and most of other libraries written in C, and they using cdecl convetion (right-to-left order, caller cleans the stack). lovely things, aren't they? so you have to triple-check your declarations when using windows. 'cause besides name mangling, you can accidentally mark some stdcall function as cdecl, and your program will work... for some time. but with bad stack pointer, which will lead to some mystical bugs later. Just one more reason to hate Windows, I guess. - Jonathan M Davis
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 02:41:11 UTC, deadalnix wrote: On Tuesday, 3 February 2015 at 15:38:06 UTC, Atila Neves wrote: How would one go about starting to be a contributor? Atila I'll start by getting the thing to build, figure out something that is not working and come to me so we can have a battle plan (or directly make a PR if this is simple) :) I guess the issue here is figuring out what does't work! :) Should I just try compiling code with sdc every now and again? I don't even know how much of the language works. The tests help a bit I guess. Atila
Re: DIP56 - inlining
On 4 February 2015 at 07:16, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: there. i still can't see what's wrong with `@attribute(inline)`, `@attribute(force_inline)` and so on. ah, except it breaks one of the first rules in The Book Of D: try to escape uniformity whenever it is possible. Using pragmas for inlining is common in compilers for other clean languages (Ada, Haskell). Unless inlining affects the ability to use functions as actual parameters it is not part of the language and therefore a pragma, but I agree that the pragma syntax is ugly, but @attribute is also ugly. Maybe better to reserve @_word so that they cannot be used for UDA and let all pragmas start with @_: @_inline(0) // never, inline_weight*0 = 0 @_inline(1) // default, inline_weight*1 = inline_weight @_inline(Inf) // always, inline_weight*Inf = Inf @_inline // same as @_inline(Inf) using `@attribute(...)` is ugly, but it has the advantage of simple workarounding for compilers that still not supporting that attribute. You can tell the compiler to ignore unknown pragmas too...
Re: Creating named tempfiles
On Wednesday, February 04, 2015 00:13:21 Jonathan M Davis via Digitalmars-d wrote: On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote: Looks like a relatively new function, so I guess, snn simply doesn't implement it. No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain _wsopen_s, which is what MS wants folks to use, but it does have _wsopen. However, when I try and use it, I get Error 42: Symbol Undefined __wsopen@16 As I understand it, snn.lib is already linked in for other stdio stuff, so I don't know why it can't find _wsopen. And adding pragma(lib, snn.lib); doesn't help. So, I don't know what to do. Oh, wait. Looking over io.h, whereas _wsopen is declared, I see two problems. One, MS declared it as int _wsopen(const wchar* filename, int oflag, int shflag, int pmode); whereas dmc seems to have int __CLIB _wsopen(const wchar_t *, int, int, ...); So, for some reason, dmc made it variadic. And the second problem is that dmc has that block of function declarations surrounded by #ifdef __NT__ #ifndef __STDC__ // declarations #endif #endif and it's quite possible that the declarations are being skipped entirely. And since changing the D declaration for _wsopen to be variadic simply changes the error message to Error 42: Symbol Undefined __wsopen@12 that would imply that those declarations aren't actually enabled. And without some version of _wsopen, I don't know how to get the code working properly on Windows. Maybe the a version will work? But those are supposed to be avoided like the plague as I understand it. All in all, this is quite annoying. - Jonathan M Davis
Re: Git, the D package manager
On Wednesday, 4 February 2015 at 01:04:42 UTC, Martin Nowak wrote: No idea why git submodule update worked the second time. You can simply use: `git submodule update --init`, which init submodules if they aren't yet. Better, write yourself an alias for clone, let's call it 'cl', which includes --recursive. I used to have one that cloned from github at a specific tag (git gcl Geod24 phobos 2.067 would clone phobos in Geod24-phobos-2.067). I wasn't aware this would break some code. submodules can be nice to work with, but you have to get use to it. Which is why I love dub, it lowers the entry barrier. Howerver, provided the feedback on this thread, it could use a step-by-step tutorial.
Re: Record separator is being lost after string cast
You can use C functions in D too: import core.stdc.stdio; ubyte[] temp = [ 65, 30, 66, 30, 67, 0]; puts(cast(char*)temp.ptr);
Re: Record separator is being lost after string cast
On Wed, 04 Feb 2015 08:13:28 +, Kadir Erdem Demir wrote: A more general and understandable code for first question : ubyte[] temp = [ 65, 30, 66, 30, 67]; writeln(temp); string tempStr = cast(string) temp; writeln (tempStr); Result is : ABC which is not desired. nothing is lost in the program. what you see is a quirk in tty output: '\x1f' is unprintable character, so you simply cannot see it. redirect the output to file and open that file in any hex editor -- and you will find your separators intact. don't beleive what you see! ;-) signature.asc Description: PGP signature
Re: DIP56 - inlining
On Wednesday, February 04, 2015 09:07:12 ketmar via Digitalmars-d wrote: D is in the same position now. that ship is sailed, we don't break the code, happy legacy, folks! Not quite. The C++ folks basically won't break backwards compatibility for anything. There are a few rare cases in the recent standards where they deprecated something that was just outright a bad idea and that no one sensible was using better anyway (e.g. non-empty throw specifiers). With D, we're reaching the point where we don't want to break backwards compatability if we can avoid it, and the bar for doing so is relatively high, but we'll still do it if we deem that the cost is worth gain (though part of the problem is how subjective that can be). So, we're not as rigid as C++ is, but we _are_ past the point where we purposefully make breaking changes on a regular basis (though unfortunately, regressions get through with pretty much every release). So, anyone looking for a particularly malleable language is going to be unhappy with D, but unlike C++, it's not set in stone. - Jonathan M Davis
Re: Creating named tempfiles
On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d wrote: for the most time `extern(Windows)` is using only for winapi calls. and `wsopen` is a library call, so it's likely an `extern(C)`. Well, unfortunately, a C function is a C function to me. I know that different calling conventions exist in Windows, but I have no idea why, what the difference is, or what they affect. AFAIK, it's not an issue that exists on POSIX systems. I really should study up on it. it's mostly historical artifacts. and it's too late to change that. most of the time it's used to make your program crash in most unexpected ways. first windows was written in pascal, so it has pascal calling convention (left-to-right order, callee cleans the stack). i don't know why, but when they go to 32-bit version, they start using stdcall calling convention (right-to-left order, yet callee still cleans the stack). that is what `extern(Windows)` in D means. and most of other libraries written in C, and they using cdecl convetion (right-to-left order, caller cleans the stack). lovely things, aren't they? so you have to triple-check your declarations when using windows. 'cause besides name mangling, you can accidentally mark some stdcall function as cdecl, and your program will work... for some time. but with bad stack pointer, which will lead to some mystical bugs later. signature.asc Description: PGP signature
[Issue 13996] Function for returning a temporary file with a randomly generated name where the name can be accessed
https://issues.dlang.org/show_bug.cgi?id=13996 --- Comment #7 from Jonathan M Davis issues.dl...@jmdavisprog.com --- Okay. I now have a pull request for this, and I added a suffix parameter to what I had so that now both a prefix and suffix can be set: https://github.com/D-Programming-Language/phobos/pull/2956 --
Re: Creating named tempfiles
On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote: Looks like a relatively new function, so I guess, snn simply doesn't implement it. No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain _wsopen_s, which is what MS wants folks to use, but it does have _wsopen. However, when I try and use it, I get Error 42: Symbol Undefined __wsopen@16 As I understand it, snn.lib is already linked in for other stdio stuff, so I don't know why it can't find _wsopen. And adding pragma(lib, snn.lib); doesn't help. So, I don't know what to do. - Jonathan M Davis
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 19:54:52 UTC, Szymon Gatner wrote: This should have happened from the start with logging library too (should have been based on boost.log) and in this case one should look into SOCI (http://soci.sourceforge.net/) and not Java versions. https://github.com/SOCI/soci/blob/master/src/core/soci-backend.h the backend interface roughly follows ADO design, but is rather big and uses polymorphic types extensively too.
Re: Git, the D package manager
On Wednesday, 4 February 2015 at 01:30:41 UTC, Martin Nowak wrote: On 02/03/2015 10:02 PM, H. S. Teoh via Digitalmars-d wrote: Rather than scan the whole source tree every time, it takes the changeset as input -- either from the OS, or from some other source of information. Indeed a good idea, although according to his graphs, this only starts to matter for +1000 files. Which is a pittance for some projects. In my previous job, the Makefiles generated by CMake were taking 8s for a no-op build, which was far too long for me. That's how I discovered Ninja. It promptly went down to 1s. But we're talking about a 100k SLOC project here, most personal repos won't see the difference. Almost all professional ones will. Atila
Re: Creating named tempfiles
On Wednesday, February 04, 2015 00:29:58 Jonathan M Davis via Digitalmars-d wrote: And the second problem is that dmc has that block of function declarations surrounded by #ifdef __NT__ #ifndef __STDC__ // declarations #endif #endif and it's quite possible that the declarations are being skipped entirely. No, on further reflection, that can't be it, because it shows up in snn.lib, not just io.h. So, it's actually in the compiled library. So, it probably is a problem with the D declaration itself - be it the calling convention or something else. - Jonathan M Davis
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 15:20:41 UTC, Vadim Lopatin wrote:
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin
wrote:
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
IMO writing:
foreach(it; db.selectUser(...)) {
}
is epic. you have entered std.(range|algorithm) land.
Implemented in v0.2.17 for select.
test:
auto ds = new ConnectionPoolDataSourceImpl(new
SQLITEDriver(), ddbctest.sqlite);
auto conn = ds.getConnection();
scope(exit) conn.close();
Statement stmt = conn.createStatement();
scope(exit) stmt.close();
// test data preparation
stmt.executeUpdate(DROP TABLE IF EXISTS user);
stmt.executeUpdate(CREATE TABLE user (id INTEGER PRIMARY
KEY, name VARCHAR(255) NOT NULL, flags int null));
stmt.executeUpdate(`INSERT INTO user (id, name, flags)
VALUES (1, John, 5), (2, Andrei, 2), (3, Walter, 2), (4,
Rikki, 3), (5, Iain, 0), (6, Robert, 1)`);
// our POD struct
struct User {
long id;
string name;
int flags;
}
// let's execute select and nump query result
foreach(user; stmt.select!User.where(id
6).orderBy(name desc)) {
writeln(id:, user.id, name:, user.name, flags:,
user.flags);
}
Output is:
--
id:3 name:Walter flags:2
id:4 name:Rikki flags:3
id:1 name:John flags:5
id:5 name:Iain flags:0
id:2 name:Andrei flags:2
--
Where and orderBy are optional - without them always reads all
rows in default order.
Possible improvements: ability to specify field list to read
only necessary fields.
Update in v0.2.19: you can specify field list for select
writeln(reading all user table rows, but fetching only id
and name (you will see default value 0 in flags field));
foreach(ref e; stmt.select!(User, id, name)) {
writeln(id:, e.id, name:, e.name, flags:,
e.flags);
}
output:
reading all user table rows, but fetching only id and name (you
will see default value 0 in flags field)
id:1 name:John flags:0
id:2 name:Andrei flags:0
id:3 name:Walter flags:0
id:4 name:Rikki flags:0
id:5 name:Iain flags:0
id:6 name:Robert flags:0
Small addition for D-style selects:
// now it's possible to use vars as destination
long id;
string name;
foreach(e; stmt.select!()(SELECT id, name FROM user, id,
name)) {
writeln(id:, id, name:, name);
}
Result:
id:1 name:John
id:2 name:Andrei
id:3 name:Walter
id:4 name:Rikki
id:5 name:Iain
id:6 name:Robert
Re: Creating named tempfiles
On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote: You got it declared with stdcall convention, should change to cdecl. Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions. for the most time `extern(Windows)` is using only for winapi calls. and `wsopen` is a library call, so it's likely an `extern(C)`. signature.asc Description: PGP signature
[Issue 14074] [REG2.067a] non-separate compilation fails, but separate compilation works
https://issues.dlang.org/show_bug.cgi?id=14074 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14074] [REG2.067a] non-separate compilation fails, but separate compilation works
https://issues.dlang.org/show_bug.cgi?id=14074 --- Comment #6 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/58163bb69e980cdc54cf3950296c370bddbbf4cc fix Issue 14074 - non-separate compilation fails, but separate compilation works https://github.com/D-Programming-Language/dmd/commit/f73fcd7d6dce1bb5cee1aed263ba470e0098590d Merge pull request #4369 from 9rnsr/fix14074 [REG2.067a] Issue 14074 - non-separate compilation fails, but separate compilation works --
Re: DIP56 - inlining
On Wed, 04 Feb 2015 08:06:06 +, eles wrote: On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote: On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote: On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote: as for uglyness... it's too late to thing about this. one more, one less... ;-) Wait... That used to be told about C++, not about D... D is in the same position now. that ship is sailed, we don't break the code, happy legacy, folks! signature.asc Description: PGP signature
Re: DIP56 - inlining
On Wed, 04 Feb 2015 08:11:40 +, Iain Buclaw via Digitalmars-d wrote: You can tell the compiler to ignore unknown pragmas too... `@attribute(...)` has another advantage: it's already working at least in one compiler. whereas proposed `pragma` is not working yet. ;-) signature.asc Description: PGP signature
Re: Creating named tempfiles
On Wed, 04 Feb 2015 00:29:58 -0800, Jonathan M Davis via Digitalmars-d wrote: Oh, wait. Looking over io.h, whereas _wsopen is declared, I see two problems. One, MS declared it as int _wsopen(const wchar* filename, int oflag, int shflag, int pmode); whereas dmc seems to have int __CLIB _wsopen(const wchar_t *, int, int, ...); So, for some reason, dmc made it variadic. `pmode` argument is optional (it depends on flags in `oflag`), and passing it each time is somewhat annoying. but there is no way to do optional args in C, so DMC made function variadic. take the first declaration, it's ok. Error 42: Symbol Undefined __wsopen@12 and yes, it must be `extern(C)`, not `extern(Windows)`, as Daniel told you in another post. signature.asc Description: PGP signature
Re: Git, the D package manager
On 2015-02-02 11:31, ketmar wrote: recently ;-) git got a feature use HEAD for submodule, which removes this limitation. If you refer to the 1.8.2 change that made it possible to track a branch in submodule. Then that doesn't make any practical difference, at least not in my experience. -- /Jacob Carlborg
Re: Git, the D package manager
On Wednesday, 4 February 2015 at 19:07:09 UTC, Jacob Carlborg wrote: On 2015-02-02 11:31, ketmar wrote: recently ;-) git got a feature use HEAD for submodule, which removes this limitation. If you refer to the 1.8.2 change that made it possible to track a branch in submodule. Then that doesn't make any practical difference, at least not in my experience. It adds tiny bit of convenience because it becomes possible to update all submodules to HEAD of their tracking branch in one go with trivial `git submodule update --remote`. But yes, it doesn't change anything in how git stores submodules in history.
Re: DIP56 - inlining
On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? -- /Jacob Carlborg
Re: Git, the D package manager
On 2015-02-02 09:09, Vladimir Panteleev wrote: 1a. rdmd and D's module system: When you run `dmd -o- program.d`, the compiler will automatically read all modules imported by your program, and their imports, and so on. It does so by searching the filesystem across its search path for matches which correspond with D's module system, and only reads those files that are needed. This doesn't work for libraries. For example, two files that don't import each other. -- /Jacob Carlborg
Re: Build managers
On Wed, 2015-02-04 at 14:17 +, Kagamin via Digitalmars-d wrote: On Monday, 2 February 2015 at 16:30:22 UTC, wobbles wrote: While I've no doubt the functionality here is good, I think following the Ant colony down the XML branch will ultimately be a pest that's hard to control. In my current job, we have ant scripts to install our dev builds that is 10k+ lines long! And noone knows all of it. A single line change gives me nightmares!! It started off nice and small, but grew to a monster. We're now moving towards gradle as we can control the install much better with a fully fledged programming environment. Should be much easier read too. Was it the type system, which gave you troubles? Groovy is said to be a dynamic language, which can be worse in managing 10kloc projects. I believe there is a crucial point here, the size of the project being build is actually irrelevant, it was that the Ant file was 10k LoC. I cannot conceive of a Gradle build system being 10k LoC, BUT if it were, then instead of all teh XML hacking to manage 10k LoC, you have a proper programming language Groovy. Groovy is optionally typed, so if you use it typeless all variables are Object. If you specify types then there is run type type checking. If you want compile time type checking of Groovy you use the @TypeChecked AST transform. If you want fully statically typed and compiled Groovy then use @CompileStatic. Yes you read that right Groovy is a fully typeless dynamic languages and it is also a fully compile-time typechecked and compile static language. What is not to like about this. As long as you are on a JVM of course. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build Systems
I had a look at different build systems, recently. Tup certainly has some progressive ideas. What I don't like is that it patronizes its users. I don't believe that tracking all file reads and writes is always a good choice. It might be a good default, though. Some other interesting build systems I came accross (in alphabetical order): - http://www.fastbuild.org - http://jpakkane.github.io/meson/ - http://shakebuild.com
Re: London D Programmers MeetUp
Thank you, Kingsley, for a very well organized and thought-through event. I was impressed by the calibre of people that attended, and look forward to attending future meetups.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 18:00:19 UTC, Jacob Carlborg wrote: On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? Interesting question. I'd say without -inline we don't perform an inline pass so nothing gets inline.
Re: GCs are complicated beasts: .NET Core, 35000 lines
On 2/4/2015 10:31 AM, Russel Winder via Digitalmars-d wrote: The Go team do not use pull requests at all, everything goes through a review manager, now that is Gerrit. Mayhap D could follow the Go example? We'd need an awful good reason to ditch the PR system we use now.
Re: GCs are complicated beasts: .NET Core, 35000 lines
On Wed, 2015-02-04 at 08:31 -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/4/15 4:09 AM, Russel Winder via Digitalmars-d wrote: BTW The Go team have completely rewritten the Go GC 1.4 → 1.5. Of course they have also completely rewritten the entire Go toolchain. Compiler, linker, runtime all written in Go now, no more C. How does the rewrite compare against the originals? -- Andrei I haven't tried them as yet. I switched from compiling the Go toolchain from Mercurial to just using released distributions (*). I think I will have to clone the Git repository and compile from there (**) (*) Fedora Rawhide packages take about 2-days to be released, Debian Sid is in freeze so they are already so far out of date with Go as to be annoying. (**) Yes you read that right, the Go team have switched from Mercurial to Git. This is not because they were unhappy with Mercurial, it is because they were unhappy with Rietveld and switched to Gerrit for their changeset handing. The Go team do not use pull requests at all, everything goes through a review manager, now that is Gerrit. Mayhap D could follow the Go example? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build managers
On Wed, 2015-02-04 at 19:26 +, Paulo Pinto via Digitalmars-d wrote: […] Well, it just manages to make my fan jump to airplane ready to takeoff mode. Improving Gradle performance is part of the Android Studio roadmap. http://tools.android.com/roadmap Looks like the Google folk working on their fork of IntelliJ IDEA are not as far down the Gradle integration as the JetBrains folk are with IntelliJ IDEA. Why don't they just pull the InteliJ IDEA stuff? Gradle has it's problems but it sounds as though yours are worse than they should be. I can't tell the difference in fan speed up between a Gradle related build and a Make-related one. My big problem is the faffing around delay after the build I get with Gradle that I do not get with SCons/Waf/CMake/Maven, and dare I say it, Ant. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: DIP56 - inlining
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough.
Re: DIP56 - inlining
On 2/4/2015 10:00 AM, Jacob Carlborg wrote: On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? With -inline: pragma(inline, true) inlines pragma(inline, false) does not inline pragma(inline) inlines at compiler's discretion Without -inline: pragma(inline, true) inlines pragma(inline, false) does not inline pragma(inline) does not inline
Re: Build managers
On Wed, 2015-02-04 at 14:20 +, Paulo Pinto via Digitalmars-d wrote: […] From my little experience with Gradle as part of Android Studio, be prepared for increased build times and CPU load vs Ant. I am just about to start doing things with Android now I can use Kotlin and Groovy to program the applications (*). I had assumed, because Android Studio is really IntelliJ IDEA, that people would use the build in project creation to make an IDEA project form the Gradle file. Any lengthy compilation of Android Studio over the old Eclipse thing should be an Eclipse vs IntelliJ IDEA thing, not a Groovy/Gradle thing. On the other hand if you use the Gradle build always then I can imagine slow start up the first time since it has to start the Gradle server. (*) I find Java 6 an appalling language. Android is getting some Java 7, but I want Java 8 and beyind, now. Kotlin and (static) Groovy provide this. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Git, the D package manager
On Wednesday, 4 February 2015 at 18:03:54 UTC, Jacob Carlborg wrote: On 2015-02-02 09:09, Vladimir Panteleev wrote: 1a. rdmd and D's module system: When you run `dmd -o- program.d`, the compiler will automatically read all modules imported by your program, and their imports, and so on. It does so by searching the filesystem across its search path for matches which correspond with D's module system, and only reads those files that are needed. This doesn't work for libraries. For example, two files that don't import each other. You mean via extern(C)? You can use pragma(lib), and the compiler will emit a linker instruction to add the specified library. I'm not sure about the platform support, though.
Re: Git, the D package manager
On 2015-02-02 09:09, Vladimir Panteleev wrote: Even if I had faith that dub was a perfectly polished piece of software, it doesn't solve any problems I have with building D programs, and in fact would make said task more complicated. Here's why. 1. rdmd rdmd is a simple and effective way to build D programs, and I'm sad to see its use declining. rdmd leverages two things: D's module system, and the compiler's import search path. Dub's design seems to ignore both of the above. I think one of the biggest advantage of Dub is the registry, code.dlang.org. Another thing is it supports a cross-platform way of configure a build. Just take a simple thing as linking a static library will most likely look different on different platforms. Also, you most likely need a wrapper script that calls rdmd with all arguments. There's basically no language that works on both Windows and Posix out of the box. The only choice is to either go with one file for Posix (shell script) and one for Windows (batch files). Or you could go with D, which seems a bit overkill for just a passing a couple of flags. -- /Jacob Carlborg
Re: Git, the D package manager
On Wednesday, 4 February 2015 at 19:15:16 UTC, Jacob Carlborg wrote: Another thing is it supports a cross-platform way of configure a build. Just take a simple thing as linking a static library will most likely look different on different platforms. Also, you most likely need a wrapper script that calls rdmd with all arguments. There's basically no language that works on both Windows and Posix out of the box. The only choice is to either go with one file for Posix (shell script) and one for Windows (batch files). Or you could go with D, which seems a bit overkill for just a passing a couple of flags. I've been using a build script for RABCDAsm since 2010, it works quite well. But then, I don't think it would be possible to replace it with a dub.json file. https://github.com/CyberShadow/RABCDAsm/blob/master/build_rabcdasm.d
Re: Git, the D package manager
On Wed, 2015-02-04 at 20:15 +0100, Jacob Carlborg via Digitalmars-d wrote: […] I think one of the biggest advantage of Dub is the registry, code.dlang.org. The success of Maven was not Maven the build system, it was Maven Central the artefact repository. OK, now superceded by JCenter, but… -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Git, the D package manager
On 2015-02-02 11:13, Vladimir Panteleev wrote: As I said in my reply to Mathias, what dub does breaks the module path and file path consistency when modules/subpackages lie in the repository root. So it's the default behavior that you don't like? I use a similar code structure as you (except the submodules) in all my dub projects. I don't have a src/source directory. -- /Jacob Carlborg
Re: Git, the D package manager
On 2015-02-02 09:58, Joseph Rushton Wakeling via Digitalmars-d wrote: Scenario: a dependency has a security hole that gets patched. If the dub package is updated, all applications using that dub package will automatically have that update available next time they are built. That's the worst kind of behavior for security reasons. It's vital that you can reproduce a build any point in time. For example, building an application now and six months later should result in the exact same binary if the code of the application has not changed. -- /Jacob Carlborg
Re: Git, the D package manager
On 2015-02-02 15:17, Manu via Digitalmars-d wrote: If I have another build tool, then I already have a build tool. Why would I want 2 build tools? Double the trouble. In my experience most build tools are to complicated, or rather, it's too complicated for simple projects. Especially if they don't directly support the target language. A build script for an executable should be as simple as: target foo That would track all dependencies of the foo.d file and build that. -- /Jacob Carlborg
Re: Build managers
On Wednesday, 4 February 2015 at 18:49:25 UTC, Russel Winder wrote: On Wed, 2015-02-04 at 14:20 +, Paulo Pinto via Digitalmars-d wrote: […] From my little experience with Gradle as part of Android Studio, be prepared for increased build times and CPU load vs Ant. I am just about to start doing things with Android now I can use Kotlin and Groovy to program the applications (*). I had assumed, because Android Studio is really IntelliJ IDEA, that people would use the build in project creation to make an IDEA project form the Gradle file. Any lengthy compilation of Android Studio over the old Eclipse thing should be an Eclipse vs IntelliJ IDEA thing, not a Groovy/Gradle thing. On the other hand if you use the Gradle build always then I can imagine slow start up the first time since it has to start the Gradle server. (*) I find Java 6 an appalling language. Android is getting some Java 7, but I want Java 8 and beyind, now. Kotlin and (static) Groovy provide this. Well, it just manages to make my fan jump to airplane ready to takeoff mode. Improving Gradle performance is part of the Android Studio roadmap. http://tools.android.com/roadmap -- Paulo
Re: Module for manual memory management
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we will
start working with it. If someone has critique, improvement suggestions
or want to take some ideas, he is free to do so.
To repeat myself: we rewrote some functionality which already existed in
D, but were improvable. For example the existing emplace method is quite
long, hard to understand / read and is not marked with @nogc. Since we
want to avoid the GC wherever possible we had to rewrite it. I hope it's
useful for someone else and that some of you guys take some ideas from it.
https://github.com/Dgame/m3
Opened File.d at random:
@trusted
@nogc
char[] read(const string filename) nothrow {
import std.c.stdio : FILE, SEEK_END, SEEK_SET, fopen, fclose,
fseek, ftell, fread;
FILE* f = fopen(filename.ptr, READ_BINARY);
scope(exit) fclose(f);
fseek(f, 0, SEEK_END);
immutable size_t fsize = ftell(f);
fseek(f, 0, SEEK_SET);
char[] str = m3.m3.make!(char[])(fsize);
fread(str.ptr, fsize, 1, f);
return str;
}
Then stopped right there. This is nowhere near production quality -
there is no error checking whatsoever, does more operations than
necessary, won't work on special files etc. etc. etc.
I applaud the intention but there is a lot more work to be done on this
before it's in reviewable form.
Andrei
Re: GCs are complicated beasts: .NET Core, 35000 lines
On 2/4/15 10:31 AM, Russel Winder via Digitalmars-d wrote: (**) Yes you read that right, the Go team have switched from Mercurial to Git. This is not because they were unhappy with Mercurial, it is because they were unhappy with Rietveld and switched to Gerrit for their changeset handing. The Go team do not use pull requests at all, everything goes through a review manager, now that is Gerrit. Mayhap D could follow the Go example? Not sure what you're proposing. I am positive we are on git and not on mercurial :o). -- Andrei
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. That was me, based on what you had posted. I will now add ... default behavior, as indicated in the command line.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. Also, the Rationale seems outdated now too. Currently: Sometimes generating better code requires runtime profile information. But being a static compiler, not a JIT, the compiler could use such hints from the programmer. I would change that rationale to this one (feel free to confirm and/or copy): Programmers will sometimes want precise control of the compiler's inlining behavior, either to improve performance in debug builds, or to be completely sure that a function is inlined, or to ensure access to the function's runtime profiling information by not inlining it. This DIP addresses those needs. Warning: Careless forcing of inlining can decrease performance dramatically. Use with caution. Also, speaking of hints to the compiler: pragma(hotcodepath, true/false); ... seems really interesting to me, although that's clearly the subject for a different DIP. I just wanted to emphasize that the current DIP is not meant to address that feature.
Re: London D Programmers MeetUp
One interesting anecdote: somebody in a financial services company gave an account of giving D a try as a way to prototype something quickly, intending to rewrite it later in a more conventional language. The prototype went straight into production, and they are happy with it. The C interop was important for them to have made this possible. It was interesting, because it is a serious company where people don't by any means have a hacker mentality, and it was one more point at variance with the I am a java programmer but do all my personal projects in D narrative, and also because this particular kind of company is exactly the sort of second wave early adopter one wants to have. (I hope I represented this accurately, and tried to make this as vague as possible whilst still keeping it useful since people might not want the details of what they do being public).
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright
wrote:
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking,
maybe it get that
later. But what do you mean with it use more operations than
necessary? I
can't see it. But both points are helpful critique. Thanks a
lot! :)
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just use it and change the allocator bit.
It would be much easier for me, if some of you would add such a
allocator to it. :P
Re: Renaming DMD File Extensions from C to C++
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? If I make a PR to make these file cpp, what are the chances for it to be accepted ? git is capable of tracking renaming, so it should create any conflict.
New DIP73: D Drafting Library
Hi, Abstract: D Drafting Library is an official library modeled by the D community and designed to support the development process of the D Standard Library. The drafting library is coupled with the standard library and doesn't introduce any duplicated functionality. It should be used during the drafting stage of the new functionality development. Link to the DIP: http://wiki.dlang.org/DIP73 and to the recent discussion for initial proposal: http://forum.dlang.org/post/rwavdkzmkqxpldveu...@forum.dlang.org Please comment, share your view and doubts. Don't hesitate to ask any question. I tried to define the proposal to be almost non-intrusive for not interested developers. I can handle point 3 and 4 from Proposal implementation steps section as a pull requests when proposal is accepted. Step 1 and 2 are trivial but can't be done by me as I'm not the person in charge. Piotrek
Re: DIP56 - inlining
On 2/4/15 12:08 PM, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. I have preliminarily approved http://wiki.dlang.org/DIP56 for post 2.067. -- Andrei
Re: H1 2015 - memory management
On 2/4/15 1:51 PM, AndyC wrote: How will we parse a string into a json struct w/out allocating memory? It will allocate, but without creating garbage. Reference counted strings are the answer. -- Andrei
Re: Concurrent Thread Safe List?
On 02/04/2015 12:10 PM, Gan wrote: I'm looking for a non-blocking way of a thread pushing objects into a list and another thread able to pull objects from the same list. Thread 1 pushes objects onto the list, Thread 2 pulls the oldest objects off the list. Does D language have something like that? The std.concurrency module does exactly that: http://dlang.org/phobos/std_concurrency.html And something I wrote: http://ddili.org/ders/d.en/concurrency.html Ali
Re: Problem with creating a new account on wiki.dlang.org
On Wednesday, 4 February 2015 at 07:02:01 UTC, Zach the Mystic wrote: Vladimir fixed it. Yay! That was quick action. Thank you both Zach and Vladimir. Piotrek
Re: Module for manual memory management
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking, maybe it get that
later. But what do you mean with it use more operations than necessary? I
can't see it. But both points are helpful critique. Thanks a lot! :)
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just use it and change the allocator bit.
Re: London D Programmers MeetUp
On 4 February 2015 at 21:17, Laeeth Isharc via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: One interesting anecdote: somebody in a financial services company gave an account of giving D a try as a way to prototype something quickly, intending to rewrite it later in a more conventional language. The prototype went straight into production, and they are happy with it. The C interop was important for them to have made this possible. It was interesting, because it is a serious company where people don't by any means have a hacker mentality, and it was one more point at variance with the I am a java programmer but do all my personal projects in D narrative, and also because this particular kind of company is exactly the sort of second wave early adopter one wants to have. (I hope I represented this accurately, and tried to make this as vague as possible whilst still keeping it useful since people might not want the details of what they do being public). That pretty much sums up my understanding of it too.
H1 2015 - memory management
The vision says We aim to make the standard library usable in its entirety without a garbage collector. Safe code should not require the presence of a garbage collector I was just playing with std.json, and this part got me to thinking. How will we parse a string into a json struct w/out allocating memory? And if I allocate memory w/out the GC, then is the caller responsible to free it? Things like string format and file read are gonna have to alloc memory, yes? How will we make std.* usable w/out the GC? -Andy
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 12:08:18 UTC, Daniel Kozak wrote: Nordlöw via Digitalmars-d píše v St 04. 02. 2015 v 10:25 +: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? If someone (maybe me) is allowed to change this I can complete my PR at https://github.com/D-Programming-Language/dmd/pull/4379 that enables developing DMD in Eclipse with full intellisense and debugging support. This is already possible without this change I've tried modifying File Types section in Properties for DMD project as: *.c - C++ Source File *.h - C++ Header File and src/*.c - C++ Source File src/*.h - C++ Header File but neith has any affect and Intellisense still fails. What do I have to do to make this work? Please help.
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 21:45:02 UTC, deadalnix wrote: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? If I make a PR to make these file cpp, what are the chances for it to be accepted ? git is capable of tracking renaming, so it should create any conflict. I managed to get things working in my latest commit in PR I mentioned above so its not critical for Eclipse integration to work.
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 21:29:17 UTC, Nordlöw wrote: I solved at Project Properties = C/C++ Build = Build command: make ENABLE_DEBUG=1 -j8 Try it out! Thanks once again, D folks. Further, to make expression.c (14klines!) by analyzed Intellisense change the limit at Preferences = Editor = Scalability to 2 lines :) Works fine for me on a three year old laptop.
Re: C++ to catch up?
Absolutely not inappropriate. I actually prefer it being a newsgroup user. Many people will instead reference a post on the forum instead of replying, and then I have to use the forum interface to see what they are talking about. I'd much rather have the full discussion in my preferred interface. Thank you, and will be clearer in future. The thing is, not everyone here is on slashdot, reddit etc. I think you can always find a place where people are hostile to your language to bitch (and some users find some sort of glee in trolling those posts to complain about the language every chance they can). Mass medium has low average quality. But for the moment, that is what people will find and many won't dig further. Someone ostensibly in a position of power to pick his platform doesn't necessarily have real power because he may have to be sensitive to what other people say - silly, superficial matters of perception matter even though they ought not to. Some day there will be a nice opportunity for someone in the field to write an article interviewing CTOs and other uses of D about their rationale and experiences, warts and all. I don't know people in tech journalism, otherwise I would try to make it happen myself. The best place to ask questions about d is on the d.learn forum. And yes, there are chronic complainers about the language here too. Sometimes their gripes are legitimate, sometimes they are not, and generally the devs are there to answer every one. Complaining is good, particularly when the energy is channeled well, as is happening with D (it seems to me). Compare and contrast England and Germany. The English don't complain as much, and so life is much more pleasant socially, but nothing works! If you have high standards, you will have many more occasions to express ways in which something can be improved. It might take you longer to finish, but the race is not always won by the swiftest. D is definitely not for mission critical applications yet, unless you are willing to work your whole business around it (e.g. Sociomantic). I am making the bet that it is, although my application is less brittle than many. I think we are in a pretty good spot right now. I'm very optimistic about the future of D. I agree, and hope we are both right.
Re: C++ to catch up?
To Zachary: The big temptation for software developers is to *promise* stability in order to attract the users they need in order to get the feedback they need in order to create the best possible design, and then break stability with the new design. Yes - economists call this time inconsistency. And I think experience shows the weakness of looking at the world in terms of people being pure rational calculators. I believe one needs to make a judgement about the people involved and their motivations and character. Ultimately you cannot protect yourself against opportunistic behaviour through contracts (although they can help). So one needs to assess track record in terms of what it indicates about character. Economists define opportunistic behaviour as self-seeking with guile - if that is the case here, they are going about it in a strange way for such highly intelligent people ;) And to Don: Thanks! Yes, I think that larger data sets are not well served by existing languages. And ease of handling large data is actually more significant than raw performance. Domains like ours are at least as much I/O bound as CPU-bound, and ability to adapt rapidly is very important. We had a discussion about this in London at drinks after the meetup. The chap who I was talking with was a very highly experienced developer who came from a C++/C/F# background, ex MS research, and was writing his own functional language. He took the position that this kind of argument in favour of native code was in many cases spurious, since one could simply scale up at low cost in the cloud (paying due regard to the difficulties of parallelisation). I found your talk very interesting, and would love to see a piece explaining from a technical perspective more on what you discuss above. But of course you must have very little time, and I doubt this comes at the top of your todo list! Perhaps Berlin chose the company, rather than the other way around :) The companies' founders all grew up in East Germany, I think they were just living in Berlin. But, there are a huge number of startups in Berlin. It's a place with great infrastructure, low costs, and available talent. So it's certainly an attractive place to launch a startup. Aha. Thanks for the colour. I think if I spoke German and the regulatory environment were a bit more favourable for finance I would be there now. The quality of life, whether you are single or have a family, certainly beats London. The thing that is frustrating is when decisions are made as if we were much further along the adoption/disruption cycle, than where we actually are. We don't yet have huge, inflexible users that demand stability at all costs. There was widespread agreement on this, from all of the eight companies at DConf who were using D commercially. Very interesting to hear. It is an interesting dynamic where the forum discussion is not necessarily representative of all the constituencies involved. Companies don't tend to hang out in forums, and its a different way of operating to do things in the open from how things are typically done in business. I haven't yet earned the right to have an opinion on the topic. Breaking changes aside, one can't say there isn't a sustained dynamism to the development of D. Yes. Though I wonder if we are putting too much emphasis on being a replacement for C++; I fear that the better we become at replacing it, the more we will duplicate its problems. But that's just a niggling doubt rather than a well-reasoned belief. Or on this one so much ;). I suppose one never truly wins the fight against entropy in all its disguises, but it is encouraging to see the people involved certainly are aware of the risk, and recent discussion over the risks of runaway language extension fit this idea. Thanks for your thoughts - I appreciate your taking the time. Laeeth
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 20:48:33 UTC, Daniel Kozak wrote: What do I have to do to make this work? Please help. Project-Properties here select use project settings and setup *.c as c++ source files and *.h as c++ header files than Project-C/C++ Index- Rebuild Thanks. So I shouldn't specify src/*.[ch] just *.[ch] then. BTW: I still can't the debugger to find source information. How and where do I the debug build configuration to call make with ENABLE_DEBUG=1 as argument?
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 21:16:15 UTC, Nordlöw wrote: BTW: I still can't the debugger to find source information. How and where do I the debug build configuration to call make with ENABLE_DEBUG=1 as argument? I tend to simply edit posix.mak and change CFLAGS there :)
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote: On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote: On 2/4/15 4:02 AM, Walter Bright wrote: On 2/4/2015 1:39 AM, ponce wrote: Would pragma(inline, bool-expr) be supported though? Yes. That's what I intended, sorry the wording wasn't clear. Please nail it down in the doc so it doesn't get neglected. -- Andrei Reading the DIP again, This adds a pragma 'inline', which is followed by an optional boolean expression, which influences the inlining of the function it appears in. An evaluation of 'true' means always inline, 'false' means never inline, and no argument means the default behavior. Seems clear enough. It just occurred to me, you might to take an small integer as the second parameter, so people can customize their whole builds: enum useDefaultInline = 0; enum useProfilingInline = 1; enum forceInlines = 2; enum inlineStrategy = forceInlines; // change this at will pragma(inline, inlineStrategy); // now you can get always, never, or default as you choose With only a bool as the second parameter, you couldn't do this.
Concurrent Thread Safe List?
I'm looking for a non-blocking way of a thread pushing objects into a list and another thread able to pull objects from the same list. Thread 1 pushes objects onto the list, Thread 2 pulls the oldest objects off the list. Does D language have something like that?
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 21:24:22 UTC, Dicebot wrote: On Wednesday, 4 February 2015 at 21:16:15 UTC, Nordlöw wrote: BTW: I still can't the debugger to find source information. How and where do I the debug build configuration to call make with ENABLE_DEBUG=1 as argument? I tend to simply edit posix.mak and change CFLAGS there :) I finally got everything to work in my latest commit at https://github.com/D-Programming-Language/dmd/pull/4379 I solved at Project Properties = C/C++ Build = Build command: make ENABLE_DEBUG=1 -j8 Try it out! Thanks once again, D folks.
Re: Git, the D package manager
On 2/5/2015 4:02 AM, Jacob Carlborg wrote: On 2015-02-02 09:58, Joseph Rushton Wakeling via Digitalmars-d wrote: Scenario: a dependency has a security hole that gets patched. If the dub package is updated, all applications using that dub package will automatically have that update available next time they are built. That's the worst kind of behavior for security reasons. It's vital that you can reproduce a build any point in time. For example, building an application now and six months later should result in the exact same binary if the code of the application has not changed. Then you specify a specific version of the library as a dependency, rather than a version range.
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we
will
start working with it. If someone has critique, improvement
suggestions
or want to take some ideas, he is free to do so.
To repeat myself: we rewrote some functionality which already
existed in
D, but were improvable. For example the existing emplace
method is quite
long, hard to understand / read and is not marked with @nogc.
Since we
want to avoid the GC wherever possible we had to rewrite it. I
hope it's
useful for someone else and that some of you guys take some
ideas from it.
https://github.com/Dgame/m3
Opened File.d at random:
@trusted
@nogc
char[] read(const string filename) nothrow {
import std.c.stdio : FILE, SEEK_END, SEEK_SET, fopen,
fclose, fseek, ftell, fread;
FILE* f = fopen(filename.ptr, READ_BINARY);
scope(exit) fclose(f);
fseek(f, 0, SEEK_END);
immutable size_t fsize = ftell(f);
fseek(f, 0, SEEK_SET);
char[] str = m3.m3.make!(char[])(fsize);
fread(str.ptr, fsize, 1, f);
return str;
}
Then stopped right there. This is nowhere near production
quality - there is no error checking whatsoever, does more
operations than necessary, won't work on special files etc.
etc. etc.
I applaud the intention but there is a lot more work to be done
on this before it's in reviewable form.
Andrei
Yes that is correct, currently there is no error checking, maybe
it get that later. But what do you mean with it use more
operations than necessary? I can't see it. But both points are
helpful critique. Thanks a lot! :)
As I said above, it's currently only for our work. But I
presented it here, so that some guys can get some inspiration or
can reuse our code. :)
Maybe, but really only maybe, I will get some work done, so that
it's is ready for phobos. But since such a review can take years,
I see no use to do that work. But if someone else has the will to
do that, reuse our code!
Re: Renaming DMD File Extensions from C to C++
On Wednesday, 4 February 2015 at 20:32:35 UTC, Nordlöw wrote: On Wednesday, 4 February 2015 at 12:08:18 UTC, Daniel Kozak wrote: Nordlöw via Digitalmars-d píše v St 04. 02. 2015 v 10:25 +: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? If someone (maybe me) is allowed to change this I can complete my PR at https://github.com/D-Programming-Language/dmd/pull/4379 that enables developing DMD in Eclipse with full intellisense and debugging support. This is already possible without this change I've tried modifying File Types section in Properties for DMD project as: *.c - C++ Source File *.h - C++ Header File and src/*.c - C++ Source File src/*.h - C++ Header File but neith has any affect and Intellisense still fails. What do I have to do to make this work? Please help. Project-Properties here select use project settings and setup *.c as c++ source files and *.h as c++ header files than Project-C/C++ Index- Rebuild
Re: Module for manual memory management
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright
wrote:
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking,
maybe it get that
later. But what do you mean with it use more operations than
necessary? I
can't see it. But both points are helpful critique. Thanks a
lot! :)
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just use it and change the allocator bit.
Yes, I've also looked at that. But I think my code is more
readable and easier to understand. But I will take a second look.
;)
BTW: You can redirect to the line by adding #194:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L194
just click on the line number on the left.
Re: This Week in D: Issue #4
On Wed, 04 Feb 2015 14:14:24 +, Adam D. Ruppe wrote: On Wednesday, 4 February 2015 at 13:50:54 UTC, wobbles wrote: p.s. Hope the search for your dog went well. Yes, we found her after she was outside for a week. Lost about 13% of her body weight and had dehydration and hypothermia, but the vet was able to treat it and it looks like she'll make a full recovery over the next month as she puts the weight back on. it's great that she's at home now. signature.asc Description: PGP signature
[Issue 14126] New: GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126
Issue ID: 14126
Summary: GITHEAD - GC seemingly corrupting memory
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pun...@coverify.org
Here is a reduced test. I am making sure that _foo does not get any value other
than 0 or 1. But still when I run this code with the GITHEAD, I get a message:
How can _foo have any other value than 0 or 1?
16777216?? really
core.exception.InvalidMemoryOperationError@(0)
Works fine with release 2.066.1.
import std.stdio;
import std.conv;
class FooBar {
private Foo[] _foos;
this() {
_foos.length = 512;
foreach(ref foo; _foos)
foo = Foo(1);
}
}
struct Foo {
private uint _foo = 0;
this(uint foo) {
assert(foo == 1);
_foo = foo;
}
~this() {
if (_foo != 0 _foo != 1) {
writeln(How can _foo have any other value than 0 or 1?);
writeln(_foo, ?? really);
assert(false, Unexpected Value: ~ _foo.to!string());
}
}
}
void main() {
auto bar = new FooBar();
}
--
