Re: Raw binary(to work without OS) in D
On Thursday, 21 June 2012 at 19:44:40 UTC, Walter Bright wrote: On 6/21/2012 9:39 AM, Alex wrote: is it possible to use D to write code to work without OS? like i do it with gcc. Sure. But you'll need to thoroughly understand how the D runtime startup code works, so you can adjust as necessary. Good luck getting the C-runtime part of the D runtime right..
Re: Raw binary(to work without OS) in D
On 6/21/2012 11:07 PM, Mehrdad wrote: On Thursday, 21 June 2012 at 19:44:40 UTC, Walter Bright wrote: On 6/21/2012 9:39 AM, Alex wrote: is it possible to use D to write code to work without OS? like i do it with gcc. Sure. But you'll need to thoroughly understand how the D runtime startup code works, so you can adjust as necessary. Good luck getting the C-runtime part of the D runtime right.. It's not that hard. But there's a lot of detail to learn take care of.
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 06:35:41 UTC, Walter Bright wrote: On 6/21/2012 11:07 PM, Mehrdad wrote: Good luck getting the C-runtime part of the D runtime right.. It's not that hard. But there's a lot of detail to learn take care of. Where do you find the detail? (Remember this, below?) http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=155617
Re: Handling of compiler patches
On Thu, 21 Jun 2012 10:51:03 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 21-Jun-12 11:40, bearophile wrote: For DMD in GitHub there are more than one hundred open pull requests (currently 111). So far people have created more than one thousand patches for DMD (currently 1022): https://github.com/D-Programming-Language/dmd/pulls Among the list of open pull requests there are some bugs and enhancement requests that I'd really like to see applied fixed in not too much time. I am not a compiler writer, but I have two suggestions for Walter (or at least to open a discussion, if the things I am saying are wrong): Instead of pushing Walter to work some other way to improve his bandwidth I'd suggest to implement proper caching first. What I suggest is to finally organize multi-stage development process that loosely models military command chain :) OK. Walter is the general at HQ (@ dlang master branch) no doubt. And some of core contributors are assigned as lieutenants for feature oriented branches. The structure I imagine is: Walter (master branch) |--- CTFE feature branch, Don Clugston |--- Backend bugfix feature branch, Brad Roberts |--- Language bugfix feature, Kenji Hara / Daniel Murphy |--- Miscellaneous ICE bugs, Martin Nowak (we can start with a few less or more of these) *Keep in mind these assignments are purely my speculation. And sure thing it doesn't prevent anybody from working on someone else feature branch. All these assignments mean is responsibility for pulling stuff and forming separate (or on the contrary - cumulative) pulls on them for HQ. Also allows them to polish and refactor things on the way up. Then the model works as follows: HQ repo gets pull requests prepared by lieutenants *only* thus *insuring* it's not some for the **ck of it pull request and lifting ton of work for reviewing it. Pulls for features are targeted at specific repo thus *insuring* there is at least one major guy how it supposed to work in this field (and in the know of proper DMD's conventions). All dirty hack pulls get stopped/re-written somewhere here. Also all of lieutenants repos should be kept rebased on top of master (HQ) at all times. Thus Walter may even choose to cherry pick some commits skipping the usual pull request process. I like this. It neatly solves a whole lot of issues. Also, this is precisely how Linus INTENDED Git to be used. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: DMD and Solaris
On Thursday, 21 June 2012 at 19:43:40 UTC, Walter Bright wrote: On 6/21/2012 10:56 AM, Paulo Pinto wrote: On Tuesday, 19 June 2012 at 20:06:28 UTC, Walter Bright wrote: On 6/19/2012 11:28 AM, Alex Rønne Petersen wrote: I think we need to be clear on this: Does DMD support Solaris? I would expect GDC and LDC to support it, but it doesn't seem like there's any maintained support for it in DMD. Not anymore - Solaris is a dead end operating system. Most enterprise customers we work with, seem to think otherwise. If someone wants to work on a Solaris port, I'm open to it. Actually I did start one, several months ago, but did not do much more than change a few version() statements. Real life keeps getting in the way :)
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 06:07:59 UTC, Mehrdad wrote: On Thursday, 21 June 2012 at 19:44:40 UTC, Walter Bright wrote: On 6/21/2012 9:39 AM, Alex wrote: is it possible to use D to write code to work without OS? like i do it with gcc. Sure. But you'll need to thoroughly understand how the D runtime startup code works, so you can adjust as necessary. Good luck getting the C-runtime part of the D runtime right.. I don't really know the runtime code of the generated binary code, but this is no different than other high level languages used for OS development, like Modula-3 or Oberon. The C runtime just needs to be replaced by an Assembly runtime that provides the ground work for the language runtime at the OS level. The way this is done on Oberon's case is well documented. After all the reason why C has so tiny runtime, is that in C the OS is the language runtime.
Re: Raw binary(to work without OS) in D
On 22-Jun-12 10:49, Mehrdad wrote: On Friday, 22 June 2012 at 06:35:41 UTC, Walter Bright wrote: On 6/21/2012 11:07 PM, Mehrdad wrote: Good luck getting the C-runtime part of the D runtime right.. It's not that hard. But there's a lot of detail to learn take care of. Where do you find the detail? (Remember this, below?) Just replace all of symbols with abort stubs. Then implement the ones you happen to actually need. http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=155617 -- Dmitry Olshansky
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 08:00:08 UTC, Dmitry Olshansky wrote: Then implement the ones you happen to actually need. Er, the question isn't WHAT to do, it's HOW. If you have any idea how to implement things like TLS, SEH, and the like, then PLEASE, share them! The point I was trying to make was, though, that this information is not being shared with anyone. Which leads me to believe that whoever has this information doesn't want people to use it for D development...
Re: csvReader read file byLine()?
Jesse Phillips wrote:
On Thursday, 21 June 2012 at 20:30:07 UTC, Jens Mueller wrote:
auto file = File(filename, r);
auto records = csvReader!(Record)(file.byLine());
Am I missing something? Was this left out for a reason or an
oversight?
Jens
You might make use of std.algorithm.joiner.
The problem is that csvParser expects a range with elements of
type
dchar. Any idea why that is required for CSV parsing?
Jens
It requires a dchar range so that Unicode support is enforced. It is
the same reason char[] is a range of dchar.
You'll have to give me some example code, my test has no issue using
joiner with byLine.
import std.stdio;
import std.algorithm;
import std.csv;
void main()
{
struct Record {
string one, two, three;
}
auto filename = file.csv;
auto file = File(filename, r);
auto records = csvReader!Record(file.byLine().joiner(\n));
foreach(r; records)
{
writeln(r);
}
}
auto file = File(test.csv, r);
auto records = csvReader!double(file.byLine().joiner(\n));
writeln(records);
The last line throws a CSVException due to some conversion error
'Floating point conversion error for input .' for the attached input.
If you change the input to
3.0
4.0
you get no exception but wrong a output of
[[4], [4]]
.
Using readText or
auto records = csvReader!Record([3.00, 4.0].joiner(\n));
works as expected.
Can you reproduce the issue? I'm running dmd2.059 on Linux.
Thanks.
Jens
3.0
4.0
Re: Raw binary(to work without OS) in D
On 22-Jun-12 12:08, Mehrdad wrote: On Friday, 22 June 2012 at 08:00:08 UTC, Dmitry Olshansky wrote: Then implement the ones you happen to actually need. Er, the question isn't WHAT to do, it's HOW. If you have any idea how to implement things like TLS, SEH, and the like, then PLEASE, share them! Look at say Win32 API. There is a way to reroute most of things you listed directly to it. I actually do this kind of stuff in my spare time. Of course your own kernel has some manner of system calls too. The point I was trying to make was, though, that this information is not being shared with anyone. If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place (e.g. real-time micro-kernel). I mean it's nothing magical, all of these things are present in say MS C compiler and people do these things with it just _fine_. Which leads me to believe that whoever has this information doesn't want people to use it for D development... Yeah, I understand how it could be frustrating, but once you are on this kind of level you usually already running circles around all of this stuff. That being said the info won't hurt of course. -- Dmitry Olshansky
std.hash design
Pull request #221 and #585 both introduce modules for a new std.hash
package. As those already change API compared to the old std.crc32 and
std.md5 modules we should probably decide on a common interface for all
std.hash modules.
These are the imho most important questions:
Free function (std.crc32) vs object(std.md5) interface
-
I think we need a object based interface anyway as md5, sha-1 etc have
too much state to pass it around conveniently.
Structs and templates vs. classes and interfaces
-
It's common to use a hash in a limited scope (like functions). So
allocating on the stack is important which favors the struct approach.
However, classes could also be allocated on the stack with scoped.
Classes+interfaces have the benefit that we could provide different
_ABI_ compatible implementations. E.g. MD5 hashes could be implemented
with D/OpenSSL wrapper/windows crypto API and we could even add a
configure switch to phobos to choose the default implementation.
Doing the same with structs likely only gives us API compatibility, so
switching the default implementation in phobos could cause trouble.
Basic design:
---
If we'll implement an object based interface (struct/class), it should
probably be an output range. Something like this:
struct/interface Hash
{
void put(const(ubyte)[] data);
void put(ubyte data);
void start(); //initialize
void reset(); //reset
ubyte[] finish(ref ubyte[] buffer = null); //See below
enum size_t hashLength; //optional? See below
}
The finish function signature is a little controversial. The length of
the result differs between hash implementations. For structs+templates
we could use static arrays, but for classes+interface we'd have to use
dynamic arrays.
toString doesn't make sense on a hash, as finish() has to be called
before a string can be generated. So a helper function could be useful.
Another open question is whether we should support 'bit hashing'.
Have a look at Piotr Szturmaj's implementation for details:
https://github.com/pszturmaj/phobos/blob/master/std/crypto/hash/base.d
Re: std.hash design
On 22-Jun-12 13:11, Johannes Pfau wrote:
Pull request #221 and #585 both introduce modules for a new std.hash
package. As those already change API compared to the old std.crc32 and
std.md5 modules we should probably decide on a common interface for all
std.hash modules.
These are the imho most important questions:
Free function (std.crc32) vs object(std.md5) interface
-
I think we need a object based interface anyway as md5, sha-1 etc have
too much state to pass it around conveniently.
Yup.
Structs and templates vs. classes and interfaces
-
It's common to use a hash in a limited scope (like functions). So
allocating on the stack is important which favors the struct approach.
That's useful especially if you use one type of hash always. (e.g. SHA-1
a-la git)
However, classes could also be allocated on the stack with scoped.
Too shitty for widespread use. +Extra indirection on each block(?).
Classes+interfaces have the benefit that we could provide different
_ABI_ compatible implementations. E.g. MD5 hashes could be implemented
with D/OpenSSL wrapper/windows crypto API and we could even add a
configure switch to phobos to choose the default implementation.
Doing the same with structs likely only gives us API compatibility, so
switching the default implementation in phobos could cause trouble.
3rd option. Provide interface/class based polymorphic wrapper on top of
structs. Come on! It's D, we can find reasonable compromise.
Basic design:
---
If we'll implement an object based interface (struct/class), it should
probably be an output range. Something like this:
struct/interface Hash
{
void put(const(ubyte)[] data);
void put(ubyte data);
void start(); //initialize
void reset(); //reset
ubyte[] finish(ref ubyte[] buffer = null); //See below
enum size_t hashLength; //optional? See below
}
The finish function signature is a little controversial. The length of
the result differs between hash implementations. For structs+templates
we could use static arrays, but for classes+interface we'd have to use
dynamic arrays.
toString doesn't make sense on a hash, as finish() has to be called
before a string can be generated. So a helper function could be useful.
Another open question is whether we should support 'bit hashing'.
Have a look at Piotr Szturmaj's implementation for details:
https://github.com/pszturmaj/phobos/blob/master/std/crypto/hash/base.d
--
Dmitry Olshansky
Re: Raw binary(to work without OS) in D
On 6/21/2012 11:49 PM, Mehrdad wrote: On Friday, 22 June 2012 at 06:35:41 UTC, Walter Bright wrote: On 6/21/2012 11:07 PM, Mehrdad wrote: Good luck getting the C-runtime part of the D runtime right.. It's not that hard. But there's a lot of detail to learn take care of. Where do you find the detail? One way is to get the library source code for the C compiler and study it.
What is rape?
Put up or shut up? First question for a programmer (?) what is rape? Is programming a rape job so no one will do it anymore.. one can only hope.. what is rape? The Ameritech post-menapausal-bitch trying to scare me? What was her name? I forget. Lucky for that ugly cunt.
Re: std.hash design
Am Fri, 22 Jun 2012 13:33:41 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: On 22-Jun-12 13:11, Johannes Pfau wrote: Pull request #221 and #585 both introduce modules for a new std.hash package. As those already change API compared to the old std.crc32 and std.md5 modules we should probably decide on a common interface for all std.hash modules. These are the imho most important questions: Free function (std.crc32) vs object(std.md5) interface - I think we need a object based interface anyway as md5, sha-1 etc have too much state to pass it around conveniently. Yup. Structs and templates vs. classes and interfaces - It's common to use a hash in a limited scope (like functions). So allocating on the stack is important which favors the struct approach. That's useful especially if you use one type of hash always. (e.g. SHA-1 a-la git) However, classes could also be allocated on the stack with scoped. Too shitty for widespread use. +Extra indirection on each block(?). Classes+interfaces have the benefit that we could provide different _ABI_ compatible implementations. E.g. MD5 hashes could be implemented with D/OpenSSL wrapper/windows crypto API and we could even add a configure switch to phobos to choose the default implementation. Doing the same with structs likely only gives us API compatibility, so switching the default implementation in phobos could cause trouble. 3rd option. Provide interface/class based polymorphic wrapper on top of structs. Come on! It's D, we can find reasonable compromise. Yeah we could indeed do that. This complicates the API a little, but it's probably still the best solution. I think I'll implement the structs first, the polymorphic wrapper can be added later.
Re: std.hash design
On Fri, 22 Jun 2012 10:11:10 +0100, Johannes Pfau nos...@example.com
wrote:
Pull request #221 and #585 both introduce modules for a new std.hash
package. As those already change API compared to the old std.crc32 and
std.md5 modules we should probably decide on a common interface for all
std.hash modules.
These are the imho most important questions:
Free function (std.crc32) vs object(std.md5) interface
-
I think we need a object based interface anyway as md5, sha-1 etc have
too much state to pass it around conveniently.
Structs and templates vs. classes and interfaces
-
It's common to use a hash in a limited scope (like functions). So
allocating on the stack is important which favors the struct approach.
However, classes could also be allocated on the stack with scoped.
Classes+interfaces have the benefit that we could provide different
_ABI_ compatible implementations. E.g. MD5 hashes could be implemented
with D/OpenSSL wrapper/windows crypto API and we could even add a
configure switch to phobos to choose the default implementation.
Doing the same with structs likely only gives us API compatibility, so
switching the default implementation in phobos could cause trouble.
Basic design:
---
If we'll implement an object based interface (struct/class), it should
probably be an output range. Something like this:
struct/interface Hash
{
void put(const(ubyte)[] data);
void put(ubyte data);
void start(); //initialize
void reset(); //reset
ubyte[] finish(ref ubyte[] buffer = null); //See below
enum size_t hashLength; //optional? See below
}
The finish function signature is a little controversial. The length of
the result differs between hash implementations. For structs+templates
we could use static arrays, but for classes+interface we'd have to use
dynamic arrays.
It might help (or it might not) to have a glance at the design of the
hashing routines in Tango:
http://www.dsource.org/projects/tango/docs/current/
(see tango.util.digest etc)
I contributed some of the initial code for these, though it has since
evolved a lot. I started with structs, mirroring the phobos MD5 code but
used all sorts of unnecessary mixins to get the code reuse I wanted. The
result was ugly :p
Later someone contacted me about it, and wanted a class based approach so
I did some refactoring and the result was much cleaner. I'm not trying to
say that a struct approach cannot be clean, just that I did a bad job of
it initially, and also structs don't lend themselves to the factory
pattern though which is a nice way to use hashing.
As Dmitry has said, we can likely get the best of both worlds with classes
wrapping structs or similar.
toString doesn't make sense on a hash, as finish() has to be called
before a string can be generated. So a helper function could be useful.
toString() could output the intermediate/internal state at the time of the
call, which if called after finish would be the hash result. I can't
recall if this has any specific usefulness, tho I have a nagging/niggling
itch which says I did use this intermediate result for something at some
stage.
It might be useful to have toString on a hash so that we can pass a
completed hash object around and repeatedly obtain the string
representation vs obtaining it once on finish and passing the string
around. However, that said, it's probably more secure to destroy and
scrub the memory used by the hash object ASAP and only retain the
resulting string or ubyte[] result.
I think I've talked myself round in a circle.. I think if we have a way to
obtain the current state as ubyte[] that would satisfy the niggle I have.
Having a separate routine for turning a ubyte[] into a hex string is
probably better than attaching toString to a hash object.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Raw binary(to work without OS) in D
On 22/06/12 10:08, Mehrdad wrote: On Friday, 22 June 2012 at 08:00:08 UTC, Dmitry Olshansky wrote: Then implement the ones you happen to actually need. Er, the question isn't WHAT to do, it's HOW. If you have any idea how to implement things like TLS, SEH, and the like, then PLEASE, share them! On Windows, all of the SEH code is in D. The C library isn't used any more. I think the main thing that's still done in C is the floating point formatting. The point I was trying to make was, though, that this information is not being shared with anyone. Which leads me to believe that whoever has this information doesn't want people to use it for D development...
Re: What is rape?
I like the way you change your name, like it fools anyone. Why on earth troll a little humble NG like this? I know you're drunk and emo, because of the shit you're posting (srsly, get over her, how long has it been at this point? Years?), but I'm curious. Bernard, 'feeding the troll'.
Re: std.hash design
Am Fri, 22 Jun 2012 12:03:27 +0100 schrieb Regan Heath re...@netmail.co.nz: It might help (or it might not) to have a glance at the design of the hashing routines in Tango: http://www.dsource.org/projects/tango/docs/current/ (see tango.util.digest etc) I contributed some of the initial code for these, though it has since evolved a lot. I started with structs, mirroring the phobos MD5 code but used all sorts of unnecessary mixins to get the code reuse I wanted. The result was ugly :p Later someone contacted me about it, and wanted a class based approach so I did some refactoring and the result was much cleaner. I'm not trying to say that a struct approach cannot be clean, just that I did a bad job of it initially, and also structs don't lend themselves to the factory pattern though which is a nice way to use hashing. I had a short look at Piotr Szturmaj's sha implementations, and it seems this kind of code would benefit a lot from inheritance. I understand that it was probably impossible to do this in D1, but don't you think 'alias this' could work in D2? This wouldn't solve the problem with the factory pattern, but that can be solved by providing wrapper classes. As Dmitry has said, we can likely get the best of both worlds with classes wrapping structs or similar. Yep, although classes wrapping structs doesn't help code reuse. But alias this should hopefully work for that. toString doesn't make sense on a hash, as finish() has to be called before a string can be generated. So a helper function could be useful. toString() could output the intermediate/internal state at the time of the call, which if called after finish would be the hash result. I can't recall if this has any specific usefulness, tho I have a nagging/niggling itch which says I did use this intermediate result for something at some stage. It might be useful to have toString on a hash so that we can pass a completed hash object around and repeatedly obtain the string representation vs obtaining it once on finish and passing the string around. However, that said, it's probably more secure to destroy and scrub the memory used by the hash object ASAP and only retain the resulting string or ubyte[] result. I think I've talked myself round in a circle.. I think if we have a way to obtain the current state as ubyte[] that would satisfy the niggle I have. Having a separate routine for turning a ubyte[] into a hex string is probably better than attaching toString to a hash object. We could also provide a finishString function or something like that. But toString returning a intermediate state would be confusing. Tango doesn't seem to offer a way to peek at the current state. But if it's really useful, it could be added. BTW: Do you know why digestSize is a function in tango? Are there digests that produce variable length hashes?
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 09:50:54 UTC, Walter Bright wrote: On 6/21/2012 11:49 PM, Mehrdad wrote: On Friday, 22 June 2012 at 06:35:41 UTC, Walter Bright wrote: On 6/21/2012 11:07 PM, Mehrdad wrote: Good luck getting the C-runtime part of the D runtime right.. It's not that hard. But there's a lot of detail to learn take care of. Where do you find the detail? One way is to get the library source code for the C compiler and study it. By get you mean buy, right? I find that to be against D's (supposedly) open-source nature...
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 08:35:51 UTC, Dmitry Olshansky wrote: Look at say Win32 API. There is a way to reroute most of things you listed directly to it. I actually do this kind of stuff in my spare time. Of course your own kernel has some manner of system calls too. I'm talking about things like PE file sections used to support TLS and whatnot. They're unrelated to the Windows API. If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place (e.g. real-time micro-kernel). You're not being helpful. I mean it's nothing magical, all of these things are present in say MS C compiler and people do these things with it just _fine_. Uh, no. D puts extra crap in the binary. Yeah, I understand how it could be frustrating, but once you are on this kind of level you usually already running circles around all of this stuff. That being said the info won't hurt of course. I guess I'm not at your majesty's High Level yet? Thanks for being so helpful.
Re: csvReader read file byLine()?
On Friday, 22 June 2012 at 08:12:59 UTC, Jens Mueller wrote:
The last line throws a CSVException due to some conversion error
'Floating point conversion error for input .' for the
attached input.
If you change the input to
3.0
4.0
you get no exception but wrong a output of
[[4], [4]]
.
Yes, and it seems .joiner isn't as lazy as I'd have thought.
byLine() reuses its buffer so it will overwrite previous lines in
the file. This can be resolved by mapping a dup to it.
import std.stdio;
import std.algorithm;
import std.csv;
void main()
{
struct Record {
double one;
}
auto filename = file.csv;
auto file = File(filename, r);
auto input = map!(a = a.idup)(file.byLine()).joiner(\n);
auto records = csvReader!Record(input);
foreach(r; records)
{
writeln(r);
}
}
Re: Raw binary(to work without OS) in D
On 22-Jun-12 18:17, Mehrdad wrote: You're not being helpful. While I usually try to help people where I can do so I didn't intend to _help_ you with this post in any capacity. Aside from Just replace all of symbols with abort stubs. Then implement the ones you happen to actually need. but you are (probably) way ahead of this advice. I mean it's nothing magical, all of these things are present in say MS C compiler and people do these things with it just _fine_. Uh, no. D puts extra crap in the binary. Like what? I'm aware only of some fancy _beg/_end sections and a bunch of stuff from DMC runtime, mostly FP math things. Yeah, I understand how it could be frustrating, but once you are on this kind of level you usually already running circles around all of this stuff. That being said the info won't hurt of course. I guess I'm not at your majesty's High Level yet? Thanks for being so helpful. No problem. I meant actually low level. Like down to hardware/OS so it's rather the opposite ;) It's not like I've asserted yours or mine levels at anything in particular at all. (that 'you' in my paragraph above should have probably been 'one' i.e. 'once one on this kind of level...') -- Dmitry Olshansky
Re: csvReader read file byLine()?
Jesse Phillips wrote:
On Friday, 22 June 2012 at 08:12:59 UTC, Jens Mueller wrote:
The last line throws a CSVException due to some conversion error
'Floating point conversion error for input .' for the attached
input.
If you change the input to
3.0
4.0
you get no exception but wrong a output of
[[4], [4]]
.
Yes, and it seems .joiner isn't as lazy as I'd have thought.
byLine() reuses its buffer so it will overwrite previous lines in
the file. This can be resolved by mapping a dup to it.
import std.stdio;
import std.algorithm;
import std.csv;
void main()
{
struct Record {
double one;
}
auto filename = file.csv;
auto file = File(filename, r);
auto input = map!(a = a.idup)(file.byLine()).joiner(\n);
auto records = csvReader!Record(input);
foreach(r; records)
{
writeln(r);
}
}
Thanks. That works. But this should be either mentioned in the
documentation or fixed. I would prefer a fix because the code above
looks like a work around. Probably byLine or joiner then need some
fixing. What do you think?
Jens
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 11:41:26 UTC, Don Clugston wrote: On Windows, all of the SEH code is in D. The C library isn't used any more. That's certainly changed a lot since the last time I looked, so that's good. But lots of other parts about D (TLS, GC, etc.) still have that problem though. I was never able to get the __xi_a, __xi_z, etc. stuff correct, and I've spent a heck of a lot of time on it. The way I'm understanding it is that the message is essentially If you want to develop your own systems with our systems programming language, then you gotta buy it, sorry. Batteries not included.
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 14:40:42 UTC, Dmitry Olshansky wrote: I guess I'm not at your majesty's High Level yet? Thanks for being so helpful. No problem. Someone can't recognize sarcasm... I meant actually low level. Like down to hardware/OS so it's rather the opposite ;) It's not like I've asserted yours or mine levels at anything in particular at all. Allow me to translate? Geez, I guess you're just an idiot for needing so much spoon-fed to you. I can land people on the moon without anyone ever telling me how. Not that I never insulted you at anything in particular. (that 'you' in my paragraph above should have probably been 'one' i.e. 'once one on this kind of level...') Oh, so now you're insulting /everyone/ like me, instead of just me! That obviously makes the situation better. Are you serious? So you're going to tell people they're just too stupid for the task if they can't figure something out by themselves?
Re: csvReader read file byLine()?
Jens Mueller , dans le message (digitalmars.D:170448), a écrit :
Jesse Phillips wrote:
On Friday, 22 June 2012 at 08:12:59 UTC, Jens Mueller wrote:
The last line throws a CSVException due to some conversion error
'Floating point conversion error for input .' for the attached
input.
If you change the input to
3.0
4.0
you get no exception but wrong a output of
[[4], [4]]
.
Yes, and it seems .joiner isn't as lazy as I'd have thought.
byLine() reuses its buffer so it will overwrite previous lines in
the file. This can be resolved by mapping a dup to it.
import std.stdio;
import std.algorithm;
import std.csv;
void main()
{
struct Record {
double one;
}
auto filename = file.csv;
auto file = File(filename, r);
auto input = map!(a = a.idup)(file.byLine()).joiner(\n);
auto records = csvReader!Record(input);
foreach(r; records)
{
writeln(r);
}
}
Thanks. That works. But this should be either mentioned in the
documentation or fixed. I would prefer a fix because the code above
looks like a work around. Probably byLine or joiner then need some
fixing. What do you think?
Jens
Yes, and that increases GC usage a lot.
Looking at the implementation, joiner as a behavior that is incompatible
with ranges reusing some buffer:
joiner immidiately call's the range of range's popFront after having
taken its front range. Instead, it should wait until it is necessary
before calling popFront (at least until all the data has be read by the
next tool of the chain).
Fixing this should not be very hard. Is there an issue preventing to
make this change?
--
Christophe
Re: Raw binary(to work without OS) in D
On 06/22/2012 04:58 PM, Mehrdad wrote: On Friday, 22 June 2012 at 14:40:42 UTC, Dmitry Olshansky wrote: I guess I'm not at your majesty's High Level yet? Thanks for being so helpful. No problem. Someone can't recognize sarcasm... I meant actually low level. Like down to hardware/OS so it's rather the opposite ;) It's not like I've asserted yours or mine levels at anything in particular at all. Allow me to translate? Geez, I guess you're just an idiot for needing so much spoon-fed to you. I can land people on the moon without anyone ever telling me how. Not that I never insulted you at anything in particular. (that 'you' in my paragraph above should have probably been 'one' i.e. 'once one on this kind of level...') Oh, so now you're insulting /everyone/ like me, instead of just me! That obviously makes the situation better. Are you serious? So you're going to tell people they're just too stupid for the task if they can't figure something out by themselves? Note that this kind of melodramatism is not helping your case. Getting insulted and shooting in all directions is genuinely stupid behaviour and wastes everyone's time. You have to realize that some of your comments have been rather impolite lately. Why do you assume that everyone else cares a lot more about how some random comment might be conceived?
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 15:12:13 UTC, Timon Gehr wrote: Note that this kind of melodramatism is not helping your case. Getting insulted and shooting in all directions is genuinely stupid behaviour and wastes everyone's time. You have to realize that some of your comments have been rather impolite lately. You mean in response to @Dmitri's comments? Or to someone else? It would be very helpful for me if you could show a couple examples of what you're referring to. Why do you assume that everyone else cares a lot more about how some random comment might be conceived? Might be conceived? Is it really just me? Okay, well then you tell me: Isn't the quote If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place just saying I'm too stupid for this to help me anyway?
Re: DMD and Solaris
On Jun 21, 2012, at 10:56 AM, Paulo Pinto pj...@progtools.org wrote: On Tuesday, 19 June 2012 at 20:06:28 UTC, Walter Bright wrote: On 6/19/2012 11:28 AM, Alex Rønne Petersen wrote: I think we need to be clear on this: Does DMD support Solaris? I would expect GDC and LDC to support it, but it doesn't seem like there's any maintained support for it in DMD. Not anymore - Solaris is a dead end operating system. Most enterprise customers we work with, seem to think otherwise. I bet they wish it were a dead operating system though :-)
Re: std.hash design
Here's a first proposal for the API: http://dl.dropbox.com/u/24218791/d/src/digest.html One open question is: What should we do if a too small buffer is passed to the finish function (in the OOP API)? Should we check for the length only in debug(assert) or in debug+release mode (enforce) or should we use the tango way and silently allocate? And another question: Can Digest.length be pure (for all digests)?
Re: Raw binary(to work without OS) in D
On 06/22/2012 05:21 PM, Mehrdad wrote: On Friday, 22 June 2012 at 15:12:13 UTC, Timon Gehr wrote: Note that this kind of melodramatism is not helping your case. Getting insulted and shooting in all directions is genuinely stupid behaviour and wastes everyone's time. You have to realize that some of your comments have been rather impolite lately. You mean in response to @Dmitri's comments? Or to someone else? It would be very helpful for me if you could show a couple examples of what you're referring to. You like blaming someone, or claiming someone has bad intentions. Eg: Which leads me to believe that whoever has this information doesn't want people to use it for D development... The way I'm understanding it is that the message is essentially If you want to develop your own systems with our systems programming language, then you gotta buy it, sorry. Batteries not included. There is no need to deduce such messages from insufficient support or documentation of a free product run 100% by volunteers. Who should such comments be directed at? What should their effect be? I only see it generating bad air. Why do you assume that everyone else cares a lot more about how some random comment might be conceived? Might be conceived? Is it really just me? Okay, well then you tell me: Isn't the quote If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place just saying I'm too stupid for this to help me anyway? I think it does not matter, because the optimal reaction would be the same in each case: ignore the comment and continue the productive part of the discussion.
Re: Raw binary(to work without OS) in D
On 22-Jun-12 19:21, Mehrdad wrote: Might be conceived? Is it really just me? Okay, well then you tell me: Isn't the quote If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place just saying I'm too stupid for this to help me anyway? I actually meant my previous post to be the last in this thread. But here it goes: 1. I classify the above as speculation on my part, namely to put it in other words (not featuring any individual): this work take a lot of low-level hacking meaning that investigating symbols output by compiler and their meaning is least of problem there usually That's ALL I meant to say here. You can frame it like advice, insult, promotion or whatever you fell like (it's not like I or someone else can stop you). 2. The sarcasm is not lost on me, but for some reason I _think_ you are/were outraged way before my post. Being outraged doesn't help sort out things 99% of time (this is my assertion you may disagree). 3. If anything the mailing list/NG is not technical support (especially general discussion ones) I'm not obliged to offer you any help. It's all about sharing opinions. So take it or ignore it and let's move on. -- Dmitry Olshansky
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 15:37:16 UTC, Timon Gehr wrote: You like blaming someone, or claiming someone has bad intentions. Eg: Which leads me to believe that whoever has this information doesn't want people to use it for D development... The way I'm understanding it is that the message is essentially If you want to develop your own systems with our systems programming language, then you gotta buy it, sorry. Batteries not included. There is no need to deduce such messages from insufficient support or documentation of a free product run 100% by volunteers. I see. I would agree if you said it was nonconstructive, but I don't see how it's /impolite/ -- at all. My intention wasn't to claim Walter (assuming that's whom you meant I was referring to) has bad intentions (I -- at least partially -- understand he can't just release the code, etc.). The trouble was that his solution to the problem was buy the source code. That's not /bad/ intentions... it simply goes against the nature of D/DMD. If his response had instead been well, I'd love to share this info, but due to legal issues I can't, then I couldn't help but sympathize. The issue is that I've asked this question a bunch of times (e.g. the one I linked to earlier), and _only now_ has anyone given any reasonable response at all for solving the problem (buy the code) -- so it only naturally makes me wonder: is that the intention of promoting? Again, wasn't trying to be impolite to Walter (or you or the others). I just find that the buy the source code comment (which, to be sure, is better than the nothing I'd gotten before) is sending completely the wrong message. If you had any other examples for where you believe I've been impolite, let me know. (Feel free to email me if you don't want to clutter here.) That would actually be helpful for me. I think it does not matter I don't... because the optimal reaction would be the same in each case: ignore the comment and continue the productive part of the discussion. I do sometimes try to do that, though I guess I'll try it more often...
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 15:45:30 UTC, Dmitry Olshansky wrote: I actually meant my previous post to be the last in this thread. But here it goes: Sorry :\ 1. I classify the above as speculation on my part, namely to put it in other words (not featuring any individual): this work take a lot of low-level hacking meaning that investigating symbols output by compiler and their meaning is least of problem there usually That's ALL I meant to say here. You can frame it like advice, insult, promotion or whatever you fell like (it's not like I or someone else can stop you). The trouble is I only see what you write, not what you think. What you're writing here is very clearly different in tone from what you said before, even if it wasn't intentional. (Usually the onus is more on the speaker to get his words across, not on the reader to try and decipher them.) 2. The sarcasm is not lost on me, but for some reason I _think_ you are/were outraged way before my post. Outraged? Not sure at what you're referring specifically... Being outraged doesn't help sort out things 99% of time (this is my assertion you may disagree). Totally agree... though (until now) I didn't see any attempt at sorting out anything. (The second comment only made things worse.) 3. If anything the mailing list/NG is not technical support (especially general discussion ones) I'm not obliged to offer you any help. It's all about sharing opinions. Yes, and I wasn't asking for you to offer me help either. But insulting people -- yeah, It's against my expectations to go on an NG and be told I'm too stupid to do something. Even if it's your opinion. So take it or ignore it and let's move on. Sure, if you'd like to. (I didn't get that message from you until now.)
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 14:11:59 UTC, Mehrdad wrote: On Friday, 22 June 2012 at 09:50:54 UTC, Walter Bright wrote: On 6/21/2012 11:49 PM, Mehrdad wrote: On Friday, 22 June 2012 at 06:35:41 UTC, Walter Bright wrote: On 6/21/2012 11:07 PM, Mehrdad wrote: Good luck getting the C-runtime part of the D runtime right.. It's not that hard. But there's a lot of detail to learn take care of. Where do you find the detail? One way is to get the library source code for the C compiler and study it. By get you mean buy, right? I find that to be against D's (supposedly) open-source nature... Well Walter can also decide to invest his time somewhere else, he needs to pay his bills...
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 16:08:13 UTC, Mehrdad wrote: The trouble is I only see what you write, not what you think. What you're writing here is very clearly different in tone from what you said before, even if it wasn't intentional. (Usually the onus is more on the speaker to get his words across, not on the reader to try and decipher them.) Comparing what Dmitry wrote earlier: If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place (e.g. real-time micro-kernel). and Yeah, I understand how it could be frustrating, but once you are on this kind of level you usually already running circles around all of this stuff. to later interpretation: 1. I classify the above as speculation on my part, namely to put it in other words (not featuring any individual): this work take a lot of low-level hacking meaning that investigating symbols output by compiler and their meaning is least of problem there usually may seem to be very different at first. But in Russian the first and the last sentences would have similar meanings. In general, it is difficult to predict how something is going to be perceived. So it is usually OK for a person to say something assuming that others will understand the intended meaning, provided that clarification is given on request. In this case, Dmitry provided a very reasonable clarification about the meaning of word 'level'. And interpretation of a statement which I quoted first is reasonably equivalent to what Dmitry provided later. (I'm from Ukraine, we speak Russian well. Dmitry is from Russia. Hope you will believe me.)
Re: std.hash design
On Fri, 22 Jun 2012 14:21:28 +0100, Johannes Pfau nos...@example.com wrote: Am Fri, 22 Jun 2012 12:03:27 +0100 schrieb Regan Heath re...@netmail.co.nz: It might help (or it might not) to have a glance at the design of the hashing routines in Tango: http://www.dsource.org/projects/tango/docs/current/ (see tango.util.digest etc) I contributed some of the initial code for these, though it has since evolved a lot. I started with structs, mirroring the phobos MD5 code but used all sorts of unnecessary mixins to get the code reuse I wanted. The result was ugly :p Later someone contacted me about it, and wanted a class based approach so I did some refactoring and the result was much cleaner. I'm not trying to say that a struct approach cannot be clean, just that I did a bad job of it initially, and also structs don't lend themselves to the factory pattern though which is a nice way to use hashing. I had a short look at Piotr Szturmaj's sha implementations, and it seems this kind of code would benefit a lot from inheritance. I understand that it was probably impossible to do this in D1, but don't you think 'alias this' could work in D2? This wouldn't solve the problem with the factory pattern, but that can be solved by providing wrapper classes. My original code was D1 and I used structs and mixins.. so perhaps alias this will solve the code re-use problem. I haven't done enough D2 to be helpful here I'm afraid. toString doesn't make sense on a hash, as finish() has to be called before a string can be generated. So a helper function could be useful. toString() could output the intermediate/internal state at the time of the call, which if called after finish would be the hash result. I can't recall if this has any specific usefulness, tho I have a nagging/niggling itch which says I did use this intermediate result for something at some stage. It might be useful to have toString on a hash so that we can pass a completed hash object around and repeatedly obtain the string representation vs obtaining it once on finish and passing the string around. However, that said, it's probably more secure to destroy and scrub the memory used by the hash object ASAP and only retain the resulting string or ubyte[] result. I think I've talked myself round in a circle.. I think if we have a way to obtain the current state as ubyte[] that would satisfy the niggle I have. Having a separate routine for turning a ubyte[] into a hex string is probably better than attaching toString to a hash object. We could also provide a finishString function or something like that. But toString returning a intermediate state would be confusing. Agreed. In fact I wouldn't bother with finishString either TBH, people can always pass the result of finish string into the method which produces the hex string representation. IIRC when I wrote my Tiger implementation it was fairly new, and I had a different method for formatting the hex string representation. Either they later changed the Tiger spec, or I was confused at the time because I have this niggling memory that I later discovered it was the same all along, or something. In any case, we can probably have one static toHexString method for all digests. Tango doesn't seem to offer a way to peek at the current state. But if it's really useful, it could be added. Probably just cobwebs in my memory, ignore me :p BTW: Do you know why digestSize is a function in tango? Are there digests that produce variable length hashes? Not to my knowledge.. perhaps there is a time/place where you want to know the size of the digest result before calculating the digest? Might be useful in generic code perhaps.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.hash design
On Fri, 22 Jun 2012 18:12:20 +0100, Regan Heath re...@netmail.co.nz wrote: people can always pass the result of finish string into the method Aargh! ..people can always pass the result of finish STRAIGHT into the method.. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Raw binary(to work without OS) in D
On 6/22/2012 7:11 AM, Mehrdad wrote: One way is to get the library source code for the C compiler and study it. By get you mean buy, right? For Digital Mars C, yes you can buy it. For gcc, you can look at the C library source code for free. I'm sure the latter does the same things. I find that to be against D's (supposedly) open-source nature... D is open source, however, that isn't necessarily true of C. For example, the Win64 version of dmd will be designed to work with Microsoft VS, which will cost $500.
Re: Raw binary(to work without OS) in D
On 6/22/2012 7:17 AM, Mehrdad wrote: On Friday, 22 June 2012 at 08:35:51 UTC, Dmitry Olshansky wrote: Look at say Win32 API. There is a way to reroute most of things you listed directly to it. I actually do this kind of stuff in my spare time. Of course your own kernel has some manner of system calls too. I'm talking about things like PE file sections used to support TLS and whatnot. They're unrelated to the Windows API. The PE file section documentation can be found by googling Windows PE file format.
Re: Raw binary(to work without OS) in D
On 6/22/2012 4:41 AM, Don Clugston wrote: On Windows, all of the SEH code is in D. The C library isn't used any more. I think the main thing that's still done in C is the floating point formatting. The startup code is done in the C library, and the thread creation stuff still relies on the C library, too.
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 17:23:38 UTC, Walter Bright wrote: D is open source, however, that isn't necessarily true of C. For example, the Win64 version of dmd will be designed to work with Microsoft VS, which will cost $500. Sorry, Walter, I didn't understand this statement. Did you mean VS will cost $500? Did you mean Win64 version of dmc (not dmd)? If no, than how will dmd be designed to work with VS?
Re: csvReader read file byLine()?
On Friday, 22 June 2012 at 15:11:14 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: Fixing this should not be very hard. Is there an issue preventing to make this change? I'd say start by filing a bug that joiner does not work with File.byLine()
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 17:06:19 UTC, Roman D. Boiko wrote: On Friday, 22 June 2012 at 16:08:13 UTC, Mehrdad wrote: The trouble is I only see what you write, not what you think. What you're writing here is very clearly different in tone from what you said before, even if it wasn't intentional. (Usually the onus is more on the speaker to get his words across, not on the reader to try and decipher them.) Comparing what Dmitry wrote earlier: If you can't figure it out on your own, chances are you won't be able to do what you wanted in the first place (e.g. real-time micro-kernel). and Yeah, I understand how it could be frustrating, but once you are on this kind of level you usually already running circles around all of this stuff. to later interpretation: 1. I classify the above as speculation on my part, namely to put it in other words (not featuring any individual): this work take a lot of low-level hacking meaning that investigating symbols output by compiler and their meaning is least of problem there usually may seem to be very different at first. But in Russian the first and the last sentences would have similar meanings. lol. I don't speak Russian, sorry. :\ For me, the first one would imply the last one, but not necessarily the other way around. In general, it is difficult to predict how something is going to be perceived. So it is usually OK for a person to say something assuming that others will understand the intended meaning, provided that clarification is given on request. I suppose? Though if someone were trying to insult you, I'm not sure if they would ever confirm, Yes, I mean to say you're an idiot, or that they would necessarily repeat it, even if you asked them. (Sad but true, I think.) So I'm not sure if you can ask for a clarification for everything... In this case, Dmitry provided a very reasonable clarification about the meaning of word 'level'. And interpretation of a statement which I quoted first is reasonably equivalent to what Dmitry provided later. Well, yes; he clearly said: I meant actually low level. Like down to hardware/OS so it's rather the opposite ;) so that would've been fine. What didn't help the situation was the other part... [...] you usually already running circles around all of this stuff With that part, it was saying, If you don't know this stuff then you shouldn't be working at this level, _NOT_ you're going to have bigger problems at this level. The implications are different. Maybe my reasoning was weird, but that's how it came across... (I'm from Ukraine, we speak Russian well. Dmitry is from Russia. Hope you will believe me.) I have no reason not to. :) But I also have a hard time integrating that fact into the rest of the discussion, since I obviously don't know Russian.
Re: std.hash design
Am Fri, 22 Jun 2012 18:12:20 +0100
schrieb Regan Heath re...@netmail.co.nz:
Agreed. In fact I wouldn't bother with finishString either TBH,
people can always pass the result of finish string into the method
which produces the hex string representation.
In any case, we can probably have one static toHexString method for
all digests.
string digestToString(size_t num)(in ubyte[num] digest)
{
auto result = new char[num*2];
size_t i;
foreach(u; digest)
{
result[i++] = std.ascii.hexDigits[u 4];
result[i++] = std.ascii.hexDigits[u 15];
}
return assumeUnique(result);
}
adapted from std.md5. I don't really like the name though ;-)
Re: Raw binary(to work without OS) in D
On 6/22/2012 7:51 AM, Mehrdad wrote: But lots of other parts about D (TLS, GC, etc.) still have that problem though. I was never able to get the __xi_a, __xi_z, etc. stuff correct, and I've spent a heck of a lot of time on it. Those are defined by Microsoft, and hold pointers to static constructors from Microsoft C generated code. It's unused by DMC, except to not muck them up in case someone links in MSC generated code.
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 17:33:17 UTC, Mehrdad wrote: I have no reason not to. :) But I also have a hard time integrating that fact into the rest of the discussion, since I obviously don't know Russian. In general, it is easy to write two very different statements in Russian which may be considered to have similar or equivalent meanings. In many cases it is OK to say something figuratively, and people will very likely perceive the meaning correctly. That may easily become a habit. This often causes me to say vague statements in English.
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 17:41:06 UTC, Roman D. Boiko wrote: On Friday, 22 June 2012 at 17:33:17 UTC, Mehrdad wrote: I have no reason not to. :) But I also have a hard time integrating that fact into the rest of the discussion, since I obviously don't know Russian. In general, it is easy to write two very different statements in Russian which may be considered to have similar or equivalent meanings. In many cases it is OK to say something figuratively, and people will very likely perceive the meaning correctly. That may easily become a habit. This often causes me to say vague statements in English. No I mean, I understand what you're saying. It's just that, well, the writer's nationality is sorta beyond my scope as a reader. :-)
Re: csvReader read file byLine()?
On Friday, June 22, 2012 19:33:39 Jesse Phillips wrote: On Friday, 22 June 2012 at 15:11:14 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: Fixing this should not be very hard. Is there an issue preventing to make this change? I'd say start by filing a bug that joiner does not work with File.byLine() http://d.puremagic.com/issues/show_bug.cgi?id=8085 - Jonathan M Davis
std.typelist
As was recently pointed out on the Phobos list ( http://forum.dlang.org/post/CAEnAdhZTcuOL50TeRwCCG=E99nCA_Gh=y=ttheugknueac0...@mail.gmail.com ), we technically have std.typelist (which I'd never heard of before that post), which Bartosz Milewski put together a few years ago. However, it's undocumented and not actually included in the build at all. The question is what to do with it. https://github.com/D-Programming-Language/phobos/blob/master/std/typelist.d It probably needs a bit of cleanup (e.g. making sure it follows the proper naming coventions everywhere), but honestly, I think that it looks pretty cool, and it probably wouldn't take much work to make it properly releasable. Do we want to have someone look it over, take it over, and submit it for review? Or do we want to simply give it a look over and fully add it after a few tweaks? Or do we want to just toss it altogether? What do we want to do with it? We really shouldn't be leaving it sitting there like it is. As it stands, it's just forgotten cruft, which is a shame, since it does look pretty cool. - Jonathan M Davis
Re: std.typelist
On 22-06-2012 20:06, Jonathan M Davis wrote: As was recently pointed out on the Phobos list ( http://forum.dlang.org/post/CAEnAdhZTcuOL50TeRwCCG=E99nCA_Gh=y=ttheugknueac0...@mail.gmail.com ), we technically have std.typelist (which I'd never heard of before that post), which Bartosz Milewski put together a few years ago. However, it's undocumented and not actually included in the build at all. The question is what to do with it. https://github.com/D-Programming-Language/phobos/blob/master/std/typelist.d It probably needs a bit of cleanup (e.g. making sure it follows the proper naming coventions everywhere), but honestly, I think that it looks pretty cool, and it probably wouldn't take much work to make it properly releasable. Do we want to have someone look it over, take it over, and submit it for review? Or do we want to simply give it a look over and fully add it after a few tweaks? Or do we want to just toss it altogether? What do we want to do with it? We really shouldn't be leaving it sitting there like it is. As it stands, it's just forgotten cruft, which is a shame, since it does look pretty cool. - Jonathan M Davis Yeah, I really think we need to ship this stuff. I might have a poke at it within the next few days. I suspect some of the unit tests might fail due to various changes in the compile-time reflection parts of the compiler over the years, so I'll probably have to fix those while I'm at it. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: std.typelist
On Fri, 22 Jun 2012 20:06:10 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: As was recently pointed out on the Phobos list ( http://forum.dlang.org/post/CAEnAdhZTcuOL50TeRwCCG=E99nCA_Gh=y=ttheugknueac0...@mail.gmail.com ), we technically have std.typelist (which I'd never heard of before that post), which Bartosz Milewski put together a few years ago. However, it's undocumented and not actually included in the build at all. I added a ticket for this back in March: http://d.puremagic.com/issues/show_bug.cgi?id=7797
Re: Raw binary(to work without OS) in D
Am 22.06.2012 19:23, schrieb Walter Bright: On 6/22/2012 7:11 AM, Mehrdad wrote: One way is to get the library source code for the C compiler and study it. By get you mean buy, right? For Digital Mars C, yes you can buy it. For gcc, you can look at the C library source code for free. I'm sure the latter does the same things. I find that to be against D's (supposedly) open-source nature... D is open source, however, that isn't necessarily true of C. For example, the Win64 version of dmd will be designed to work with Microsoft VS, which will cost $500. I'm afright. Please explain what is meant by this, Walter.
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 18:26:22 UTC, mta`chrono wrote: Am 22.06.2012 19:23, schrieb Walter Bright: D is open source, however, that isn't necessarily true of C. For example, the Win64 version of dmd will be designed to work with Microsoft VS, which will cost $500. I'm afright. Please explain what is meant by this, Walter. I also asked for clarification a few posts before. Most likely Walter meant that DMC (not DMD) for Win64 will work with Visual Studio, which is not free. Also DMC is not free, but it costs way below $500.
Re: Raw binary(to work without OS) in D
On 6/22/2012 10:28 AM, Roman D. Boiko wrote: Did you mean VS will cost $500? Yes (or whatever price MS sets it at). Did you mean Win64 version of dmc (not dmd)? No. I meant dmd for Win64. If no, than how will dmd be designed to work with VS? By emitting code that will link with VS code libraries.
Re: Raw binary(to work without OS) in D
On 22-Jun-12 20:08, Mehrdad wrote: On Friday, 22 June 2012 at 15:45:30 UTC, Dmitry Olshansky wrote: I actually meant my previous post to be the last in this thread. But here it goes: Sorry :\ 1. I classify the above as speculation on my part, namely to put it in other words (not featuring any individual): this work take a lot of low-level hacking meaning that investigating symbols output by compiler and their meaning is least of problem there usually That's ALL I meant to say here. You can frame it like advice, insult, promotion or whatever you fell like (it's not like I or someone else can stop you). The trouble is I only see what you write, not what you think. What you're writing here is very clearly different in tone from what you said before, even if it wasn't intentional. (Usually the onus is more on the speaker to get his words across, not on the reader to try and decipher them.) Sorry, like Roman said I'm not native speaker. And I'm not sure of the emotional component of things I type. To be honest no matter what form I use I tend to be neutral in general (or so I thought). (Except some very rare cases. I recall that I told something harsh in response to the brilliant idea of turning enforce into assert with some version statement) 2. The sarcasm is not lost on me, but for some reason I _think_ you are/were outraged way before my post. Outraged? Not sure at what you're referring specifically... I meant something like this: Good luck getting the C-runtime part of the D runtime right.. ... If you have any idea how to implement things like TLS, SEH, and the like, then PLEASE, share them! You were almost shouting or demanding (or so it seemed to me). I think this was the first time I insulted somebody uninterruptedly and that went totally unexpected for me. Being outraged doesn't help sort out things 99% of time (this is my assertion you may disagree). Totally agree... though (until now) I didn't see any attempt at sorting out anything. (The second comment only made things worse.) Good. And bad, as it seems I need to refresh my word/phrase selection :) 3. If anything the mailing list/NG is not technical support (especially general discussion ones) I'm not obliged to offer you any help. It's all about sharing opinions. Yes, and I wasn't asking for you to offer me help either. But insulting people -- yeah, It's against my expectations to go on an NG and be told I'm too stupid to do something. Even if it's your opinion. If anything I'm not about to make any statements aimed at a particular person. If there was insult, I'm sorry as I failed to spot emotional context of things I posted. So take it or ignore it and let's move on. Sure, if you'd like to. (I didn't get that message from you until now.) OK, glad we are (sort of) having some agreement. -- Dmitry Olshansky
Re: Raw binary(to work without OS) in D
On 22-Jun-12 22:47, Walter Bright wrote: On 6/22/2012 10:28 AM, Roman D. Boiko wrote: Did you mean VS will cost $500? Yes (or whatever price MS sets it at). I believe SDK with compiler is a free download though I might be off on this. Did you mean Win64 version of dmc (not dmd)? No. I meant dmd for Win64. If no, than how will dmd be designed to work with VS? By emitting code that will link with VS code libraries. Great. -- Dmitry Olshansky
Re: for() with 4 arguments to allow postcondition
Isn't this what a do-while loop is for, or am I missing
something?
Well, yes, but then you don't need the regular for loop either.
After all, isn't that what a while loop is for?
The big advantage of for is that you can see at a glance what
the initialisation, condition(s) and increments are. It describes
the whole loop in one statement. That's the only reason why it
was invented in the first place, because the language technically
does not need it. You can even declare the variable right there
so its scope is limited to the loop. With a do-while, you first
initialize the variable before the loop (outside of it), then add
the increment just before the end (many pages later, perhaps),
and the condition at the very end. It's all over the place.
foreach(i; 0..10)
I know my simple example would be optimized, and can indeed be
written with a foreach as well. But if you use some custom class
as the variable, or a pointer, it won't be. For example, turn i
into a Bigint. Or for an entirely different example:
for (Display * d = firstDisplay; d != 0; d = nextDisplay)
if you have already established that at least one display is
present.
Or even simpler:
for (int i = 1; i = 0x1000; i = 1)
I bet this won't be optimized on many compilers.
And all it would take is one extra semicolon:
for (Display * d = firstDisplay; ; d != 0; d = nextDisplay)
for (int i = 1; ; i = 0x1000; i = 1)
to tell the compiler to skip the condition before the first
iteration.
for(initializer;;increment){
if(!condition1) break;
body;
if(!condition2) break;
}
Yes, that's exactly what I meant.
Michel
Re: std.typelist
Wow, I never noticed that this file exists, even though I'm routinely doing metaprogramming-heavy stuff… The obligatory references to other »meta« code: [1] https://github.com/sinfu/phobos-sandbox/blob/master/std/internal/meta/meta.d [2] https://github.com/PhilippeSigaud/dranges/blob/master/templates.d [3] https://gist.github.com/1191885 (this was a one-off selection of my own code for a NG discussion, feel free to ask for more/an updated version) On Friday, 22 June 2012 at 18:10:38 UTC, Alex Rønne Petersen wrote: On 22-06-2012 20:06, Jonathan M Davis wrote: The question is what to do with it. […] Yeah, I really think we need to ship this stuff. I'd rather not ship it without more consideration and a proper review process. Yes, functionality supporting more advanced manipulation of compile time lists/tuples is definitely needed (cf. the countless std.meta discussions), but: 1) The term TypeList does not make much sense at all, as compile time tuples/lists aren't at all restricted to types. In retrospect, giving TypeTuples the name they bear was a mistake, we shouldn't repeat it. The genreral template would become meta.List (no, I never got around to finishing my proposal), and a meta.TypeList constructor could then ensure that only types are accepted (similar for meta.ExprList, or whatever good names there might be). 2) I'm not sure if introducing a concept which is essentially the same as TypeTuple, but doesn't entirely replace it for »high-level« use, is the right way to go. Yes, functional-style head/tail lists are a natural fit for many meta-algorithms, since the semantics of templates mostly require a very functional style anyway (you'll frequently see T[0] and T[1 .. $] in type tuples-heavy code). And yes, the »auto-expanding« property of TypeTuples can sometimes lead to unexpected results, and for some »higher-order« templates, you need to confine them into another template (imagine TypeList with only toTuple, see [1], [3]). But on the other hand, type tuples are deeply anchored in the language (variadics, ...), and better match the general array/range theme of D, thus probably reducing »mental overhead« for people not used to functional programming. This is not to say that I don't find the std.typelist concept interesting. We just should be very clear on how to go forward with »meta« algorithms in Phobos before going forward with this. Developing std.typelist and std.typetuple side by side, and then at some later point also introducing std.meta doesn't make much sense, in my eyes. 3) I think going for an explicit »apply« method for template predicate is not worth the hassle in the general case (in user code, which usually just passes predicates to higher order templates). Instead, I prefer using an explicit Apply/Instantiate template where needed to overcome grammar limitations, which mostly is in the implementation of the primitives. 4) I know this is picking nits at this stage, but I think And/Or should implement short-cut evaluation, like in [3]. One more thing I noticed is that the module doc comment solely lists Bartosz as the author, but the file has another copyright comment mentioning Burton Radons. This situation should definitely be clarified. David
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 18:52:41 UTC, Dmitry Olshansky wrote: Sorry, like Roman said I'm not native speaker. And I'm not sure of the emotional component of things I type. To be honest no matter what form I use I tend to be neutral in general (or so I thought). Yeah I'm not a native either, so that doesn't help me so much either... :\ (Though I guess, from another perspective, learning English has also helped me a lot. :P my point's there though.) I meant something like this: Good luck getting the C-runtime part of the D runtime right.. ... If you have any idea how to implement things like TLS, SEH, and the like, then PLEASE, share them! You were almost shouting or demanding (or so it seemed to me). I think this was the first time I insulted somebody uninterruptedly and that went totally unexpected for me. Ah. I wasn't demanding :-) shouting is closer but I wasn't trying to be yelling at anyone :P it just shows I didn't communicate well either. :) If anything I'm not about to make any statements aimed at a particular person. If there was insult, I'm sorry as I failed to spot emotional context of things I posted. Sorry about my misunderstanding as well -- my inference engine kinda failed at inferring what you meant. :P OK, glad we are having some agreement. Yup :)
Re: Raw binary(to work without OS) in D
On Jun 22, 2012, at 11:47 AM, Walter Bright wrote: On 6/22/2012 10:28 AM, Roman D. Boiko wrote: Did you mean VS will cost $500? Yes (or whatever price MS sets it at). I think there's a free version of VS.
Re: Add := digraph to D
I believe that auto has been redefined in C++11 as well. In both, all it really means is that the type is inferred. That's what I seemed to remember as well. Originally it had something to do with scope, but it was basically obsolete because that was the default storage class anyway, so nobody was using it. In the latest iteration of C++ they decided to redefine the keyword to mean automatic type inference. This avoided having to introduce a new keyword (which could break existing code that happened to use that word for a variable name) and it was unlikely to cause problems with old code. Storage class for local variables is still the same default anyway. (The only possible error could be if someone wrote auto a = b as shorthand for auto int a = b with b some type other than int, which would have been legal in very old versions of C but extremely unlikely to ever be used since auto does nothing for an int)
Re: Raw binary(to work without OS) in D
On Fri, Jun 22, 2012 at 1:19 PM, Sean Kelly s...@invisibleduck.org wrote: On Jun 22, 2012, at 11:47 AM, Walter Bright wrote: On 6/22/2012 10:28 AM, Roman D. Boiko wrote: Did you mean VS will cost $500? Yes (or whatever price MS sets it at). I think there's a free version of VS. Yes, Visual Studio Express. They had announced that Visual Studio Express 2012 wouldn't support native applications (only target Window 8's WinRT) but they have since reversed that decision. Unless there is some other obstacle that gets in the way Win64 DMD users should be able to get everything they need for free. Regards, Brad Anderson
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 18:56:48 UTC, Dmitry Olshansky wrote: I believe SDK with compiler is a free download though I might be off on this. Also, there are Express editions of Visual Studio which are currently, and will be at least for the next release, free for download. Originally, Microsoft wanted to include only the SDK for »Metro-style« apps with VC++ 2012 Express, but after this caused massively negative reactions in the developer/internet/open-source/… community, a native code edition was announced as well. David
Re: std.typelist
On 22-06-2012 21:13, David Nadlinger wrote: Wow, I never noticed that this file exists, even though I'm routinely doing metaprogramming-heavy stuff… The obligatory references to other »meta« code: [1] https://github.com/sinfu/phobos-sandbox/blob/master/std/internal/meta/meta.d [2] https://github.com/PhilippeSigaud/dranges/blob/master/templates.d [3] https://gist.github.com/1191885 (this was a one-off selection of my own code for a NG discussion, feel free to ask for more/an updated version) On Friday, 22 June 2012 at 18:10:38 UTC, Alex Rønne Petersen wrote: On 22-06-2012 20:06, Jonathan M Davis wrote: The question is what to do with it. […] Yeah, I really think we need to ship this stuff. I'd rather not ship it without more consideration and a proper review process. Yes, functionality supporting more advanced manipulation of compile time lists/tuples is definitely needed (cf. the countless std.meta discussions), but: 1) The term TypeList does not make much sense at all, as compile time tuples/lists aren't at all restricted to types. In retrospect, giving TypeTuples the name they bear was a mistake, we shouldn't repeat it. The genreral template would become meta.List (no, I never got around to finishing my proposal), and a meta.TypeList constructor could then ensure that only types are accepted (similar for meta.ExprList, or whatever good names there might be). 2) I'm not sure if introducing a concept which is essentially the same as TypeTuple, but doesn't entirely replace it for »high-level« use, is the right way to go. Yes, functional-style head/tail lists are a natural fit for many meta-algorithms, since the semantics of templates mostly require a very functional style anyway (you'll frequently see T[0] and T[1 .. $] in type tuples-heavy code). And yes, the »auto-expanding« property of TypeTuples can sometimes lead to unexpected results, and for some »higher-order« templates, you need to confine them into another template (imagine TypeList with only toTuple, see [1], [3]). But on the other hand, type tuples are deeply anchored in the language (variadics, ...), and better match the general array/range theme of D, thus probably reducing »mental overhead« for people not used to functional programming. This is not to say that I don't find the std.typelist concept interesting. We just should be very clear on how to go forward with »meta« algorithms in Phobos before going forward with this. Developing std.typelist and std.typetuple side by side, and then at some later point also introducing std.meta doesn't make much sense, in my eyes. 3) I think going for an explicit »apply« method for template predicate is not worth the hassle in the general case (in user code, which usually just passes predicates to higher order templates). Instead, I prefer using an explicit Apply/Instantiate template where needed to overcome grammar limitations, which mostly is in the implementation of the primitives. 4) I know this is picking nits at this stage, but I think And/Or should implement short-cut evaluation, like in [3]. One more thing I noticed is that the module doc comment solely lists Bartosz as the author, but the file has another copyright comment mentioning Burton Radons. This situation should definitely be clarified. David Well, author is not necessarily the same as copyright holder. Author usually means maintainer or previous maintainer, while copyright could simply indicate that some code was borrowed. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Raw binary(to work without OS) in D
On 22-Jun-12 23:23, David Nadlinger wrote: Originally, Microsoft wanted to include only the SDK for »Metro-style« apps with VC++ 2012 Express, but after this caused massively negative reactions in the developer/internet/open-source/… community, a native code edition was announced as well. David Yay! P.S. Sorry can't resist ;) -- Dmitry Olshansky
Re: Raw binary(to work without OS) in D
On Friday, 22 June 2012 at 18:56:48 UTC, Dmitry Olshansky wrote: On 22-Jun-12 22:47, Walter Bright wrote: On 6/22/2012 10:28 AM, Roman D. Boiko wrote: Did you mean VS will cost $500? Yes (or whatever price MS sets it at). I believe SDK with compiler is a free download though I might be off on this. Correct. VS SDK is free, the same is true for Windows SDK. Also there are VS express and VS shell, which are also free. But I'm sure that Visual Studio itself is not a dependency and there is nothing to link to in it, only in SDKs.
Re: Add := digraph to D
I believe that auto has been redefined in C++11 as well. In both, all it really means is that the type is inferred. That's what I seemed to remember as well. Originally it had something to do with scope, but it was basically obsolete because that was the default anyway, so nobody was using it. In the latest iteration of C++ they decided to redefine the keyword to mean automatic type inference. This avoided having to introduce a new keyword (which could break existing code that happened to use that word for a variable name) and it was unlikely to cause problems with old code. Storage class for local variables is still the same default anyway so any code that relied on variables being old-style auto would still work the same. The only possible error could be if someone wrote auto a = b as shorthand for auto int a = b with b some type other than int, which would have been legal in very old versions of C but extremely unlikely to ever be used since auto does nothing for an int. They decided to take that chance :-)
Re: std.typelist
On 06/22/12 21:13, David Nadlinger wrote: This is not to say that I don't find the std.typelist concept interesting. We just should be very clear on how to go forward with »meta« algorithms in Phobos before going forward with this. Developing std.typelist and std.typetuple side by side, and then at some later point also introducing std.meta doesn't make much sense, in my eyes. +1, I'd add std.typecons to this list ( std.typecons.Tuple in particular ). The boundaries of each of those modules are kind of blurry and overlapping.
Re: for() with 4 arguments to allow postcondition
On 06/22/2012 08:57 PM, Michel Colman wrote: Isn't this what a do-while loop is for, or am I missing something? Well, yes, but then you don't need the regular for loop either. After all, isn't that what a while loop is for? The big advantage of for is that you can see at a glance what the initialisation, condition(s) and increments are. It describes the whole loop in one statement. That's the only reason why it was invented in the first place, because the language technically does not need it. You can even declare the variable right there so its scope is limited to the loop. With a do-while, you first initialize the variable before the loop (outside of it), then add the increment just before the end (many pages later, perhaps), and the condition at the very end. It's all over the place. foreach(i; 0..10) I know my simple example would be optimized, and can indeed be written with a foreach as well. But if you use some custom class as the variable, or a pointer, it won't be. For example, turn i into a Bigint. foreach-range works with custom types. Or for an entirely different example: for (Display * d = firstDisplay; d != 0; d = nextDisplay) if you have already established that at least one display is present. If firstDisplay is trivially non-null, the compiler will remove the comparison. Furthermore, the additional comparison is extremely cheap and will likely be completely unnoticeable. Or even simpler: for (int i = 1; i = 0x1000; i = 1) I bet this won't be optimized on many compilers. I bet this is optimized on any halfway decent optimizing compiler. This is the kind of simple optimization compilers are good at. And all it would take is one extra semicolon: for (Display * d = firstDisplay; ; d != 0; d = nextDisplay) for (int i = 1; ; i = 0x1000; i = 1) to tell the compiler to skip the condition before the first iteration. The examples do not make a compelling case.
Re: std.typelist
On Friday, 22 June 2012 at 19:52:37 UTC, Guillaume Chatelet wrote: +1, I'd add std.typecons to this list ( std.typecons.Tuple in particular ). The boundaries of each of those modules are kind of blurry and overlapping. std.typecons.Tuple lives in the run-time (and CTFE, for that matter) domain, while the stuff discussed here happens in the compile-time type system) world There are some situations in which this line is blurred (e.g. in the case of »type tuples of runtime values«, like you get for variadic template functions), but there is a deep conceptual difference between the two modules. David
Allocate an Array!T on the heap?
import std.container;
struct A {};
void main()
{
Array!(A)* arr = new Array!(A);
}
yields
bug.d(7): Error: template std.container.Array!(A).Array.__ctor
does not match any function template declaration
/usr/include/d/std/container.d(1625): Error: template
std.container.Array!(A).Array.__ctor(U) if
(isImplicitlyConvertible!(U,T)) cannot deduce template function
from argument types !()()
Re: Object Cast
Seems to me that you achieved the your first purpose. Do you need more help? Kenji Hara I think i'm finished. Or have you any tip for me, related to the code?
Re: how to handle shared arrays?
Well, maybe idup is a bit better then assumeuniqe. I don't work anymore with that mutable array on the workerthread but using idup is in all cases allowed and cannot cause subtle bugs like me reusing a mutable array that I've casted to immutable and send over to another thread. It's a shame that shared doesn't (yet) work, It looks a bit dirty to convert to immutable and back to mutable simply to pass it over to another thread...
Re: how to handle shared arrays?
On Friday, June 22, 2012 11:09:13 maarten van damme wrote: It looks a bit dirty to convert to immutable and back to mutable simply to pass it over to another thread... It is, but casting to shared and back again is pretty much the same thing. So, in most cases, you're going to end up doing one or the other if you're trying to pass ownership across threads rather than sending an immutable duplicate across. It would be great if there were a way in the type system to model transfering ownership from one thread to another, but there isn't (if nothing else, because it's not easy to do), so you get to choose between transferring ownship using dirty casts and duplicating data to send it across. Certainly, if efficiency isn't an issue, iduping is safer, since it's @safe rather than @system. - Jonathan M Davis
to!(ubyte[])()
Bug or by design? (using dmd head)
import std.conv;
void main() {
to!(ubyte[])();
}
std/array.d(493): Attempting to fetch the front of an empty array of
immutable(char)
to(_d_assert_msg+0x45) [0x43700d]
to(@property dchar
std.array.front!(immutable(char)[]).front(immutable(char)[])+0x4c)
[0x42f2b8]
to(ubyte[] std.conv.parse!(ubyte[], immutable(char)[]).parse(ref
immutable(char)[], dchar, dchar, dchar).void
parseCheck!(_D3std4conv17__T5parseTAhTAyaZ5parseFKAyawwwZAh1sAya).parseCheck(dchar,
immutable(char)[], ulong)+0x2f) [0x43482b]
to(ubyte[] std.conv.parse!(ubyte[], immutable(char)[]).parse(ref
immutable(char)[], dchar, dchar, dchar)+0x49) [0x42f50d]
to(ubyte[] std.conv.toImpl!(ubyte[],
immutable(char)[]).toImpl(immutable(char)[])+0x31) [0x42f619]
to(ubyte[]
std.conv.to!(ubyte[]).to!(immutable(char)[]).to(immutable(char)[])+0x20)
[0x42f268]
to(_Dmain+0x1a) [0x42f242]
const behaviour
Based to the current const discussions (once again) I wanted to
appease my curiosity and want to ask why the following code works
as described in the comments:
[code]
import std.stdio;
class Bar { }
class Foo {
private:
string _text;
Bar _b;
public:
this(string text, Bar b) {
this._text = text;
this._b = b;
}
// const_behaviour.d(18): Error: cannot implicitly convert
expression (this._b) of type const(Bar) to const_behaviour.Bar
Bar GetB() const pure nothrow { /// - must be const(Bar)
instead of Bar
return this._b;
}
string GetText() const pure nothrow { /// - no const(string) is
neccessary. Why?
return this._text;
}
}
void main() {
Bar b = new Bar();
Foo f = new Foo(foobar, b);
}
[/code]
Re: Allocate an Array!T on the heap?
On 06/22/2012 08:45 AM, Tobias Pankrath wrote:
import std.container;
struct A {};
void main()
{
Array!(A)* arr = new Array!(A);
}
yields
bug.d(7): Error: template std.container.Array!(A).Array.__ctor does not
match any function template declaration
/usr/include/d/std/container.d(1625): Error: template
std.container.Array!(A).Array.__ctor(U) if
(isImplicitlyConvertible!(U,T)) cannot deduce template function from
argument types !()()
This seems to work:
import std.container;
struct A {};
void main() {
auto arr = new Array!A(A.init);
}
Stack overflow
I have this code: http://codepad.org/vz17iZrm And as long as i comment out the assert's in the constructor on line 10 and the assert in the invariant on line 16 it works as i want. But otherwise the compiler prints stackoverflow and that's all. Why and how is the stack overflowed with an simple assert?!
Re: const behaviour
On 06/22/2012 11:21 AM, Namespace wrote:
Based to the current const discussions (once again) I wanted to appease
my curiosity and want to ask why the following code works as described
in the comments:
[code]
import std.stdio;
class Bar { }
class Foo {
private:
string _text;
Bar _b;
public:
this(string text, Bar b) {
this._text = text;
this._b = b;
}
// const_behaviour.d(18): Error: cannot implicitly convert
expression (this._b) of type const(Bar) to const_behaviour.Bar
Bar GetB() const pure nothrow { /// - must be const(Bar) instead
of Bar
return this._b;
}
string GetText() const pure nothrow { /// - no const(string) is
neccessary. Why?
return this._text;
}
}
void main() {
Bar b = new Bar();
Foo f = new Foo(foobar, b);
}
[/code]
string is immutable(char)[] and const(immutable(char)[]) implicitly
converts to immutable(char)[]. Or put differently, a string doesn't
have to be const-qualified because it cannot be changed anyway.
Re: const behaviour
As far as i know int is not immutable or const by default.
So, why work this code:
[code]
import std.stdio;
class Bar {
}
class Foo {
private:
int _id;
Bar _b;
public:
this(int id, Bar b) {
this._id = id;
this._b = b;
}
// const_behaviour.d(18): Error: cannot implicitly convert
expression (this._b) of type const(Bar) to const_behaviour.Bar
const(Bar) GetB() const pure nothrow { /// - must be const(Bar)
instead of Bar
return this._b;
}
int GetId() const pure nothrow { /// - no const(int) is
neccessary. Why?!
return this._id;
}
}
void main() {
Bar b = new Bar();
Foo f = new Foo(42, b);
}
[/code]
Re: Stack overflow
On 22-06-2012 12:22, Namespace wrote: I have this code: http://codepad.org/vz17iZrm And as long as i comment out the assert's in the constructor on line 10 and the assert in the invariant on line 16 it works as i want. But otherwise the compiler prints stackoverflow and that's all. Why and how is the stack overflowed with an simple assert?! Wow, you really managed to dig up some compiler bugs here. OK, so first of all, if you change the asserts to assert(obj); and assert(_obj); (I assume this is what you meant in the invariant), the code compiles. This is clearly a bug. Now, if you change the first assert to assert(obj); and the one in the invariant to assert(obj); *too* (invalid code), the compiler just plain seg faults. The workaround, as mentioned, is to either use assert(obj); and assert(_obj); or assert(!!obj); and assert(!!_obj);. The reason the latter forms may be desirable is that the former calls obj's invariant in addition to checking for null. The latter doesn't. In any case, please file bugs for these issues. You really managed to run into some unusually broken parts of the compiler, it seems. :-/ -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Stack overflow
On 06/22/2012 12:22 PM, Namespace wrote: I have this code: http://codepad.org/vz17iZrm And as long as i comment out the assert's in the constructor on line 10 and the assert in the invariant on line 16 it works as i want. But otherwise the compiler prints stackoverflow and that's all. Why and how is the stack overflowed with an simple assert?! On my machine it is the compiler that crashes = compiler bug. Presumably it is having trouble with the circular alias this. (BTW, what is 'obj' in the invariant supposed to refer to?)
Re: to!(ubyte[])()
On Friday, 22 June 2012 at 09:18:38 UTC, simendsjo wrote:
Bug or by design? (using dmd head)
import std.conv;
void main() {
to!(ubyte[])();
}
std/array.d(493): Attempting to fetch the front of an empty
array of immutable(char)
[snip]
It is design. With the conversion from string to non-string type,
std.conv.to runs parsing.
import std.conv;
void main()
{
auto arr = to!(ubyte[])([1,2,3]);
// parse given string as a representation of ubyte[] value.
assert(arr == [1,2,3]);
}
And, the representation string of a value should have one or more
characters.
So empty string always throws exception.
Kenji Hara
Re: const behaviour
On 06/22/2012 12:25 PM, Namespace wrote:
As far as i know int is not immutable or const by default.
So, why work this code:
[code]
import std.stdio;
class Bar {
}
class Foo {
private:
int _id;
Bar _b;
public:
this(int id, Bar b) {
this._id = id;
this._b = b;
}
// const_behaviour.d(18): Error: cannot implicitly convert
expression (this._b) of type const(Bar) to const_behaviour.Bar
const(Bar) GetB() const pure nothrow { /// - must be const(Bar)
instead of Bar
return this._b;
}
int GetId() const pure nothrow { /// - no const(int) is
neccessary. Why?!
return this._id;
}
}
void main() {
Bar b = new Bar();
Foo f = new Foo(42, b);
}
[/code]
The same reason, because const(int) implicitly converts to int. If the
data is copied, the qualifiers can be changed in any way that is
desired. As string, int has no mutable indirections.
Re: Stack overflow
On my machine it is the compiler that crashes = compiler bug. Presumably it is having trouble with the circular alias this. My first try to avoid this circular bug work with opDispatch. (As you can read here on my blog: http://blog.rswhite.de/archives/741) Now i had a new idea to save the Reference and call only these, it seems that it works fine and with a lot less code. (BTW, what is 'obj' in the invariant supposed to refer to?) Just for testing. ;) @Alex Rønne Petersen: Thanks a lot, i use assert(obj); that seems to serve the purpose. I hope in the next version alias this is more stable.
immutable ref foreach on values
Is this expected and good?
void main() {
int[] array = [1, 2];
foreach (ref const(int) x; array) {} // OK
foreach (ref immutable(int) x; array) {} // error
}
DMD 2.060alpha:
temp.d(4): Error: argument type mismatch, int to ref
immutable(int)
Thank you,
bye,
bearophile
Re: Allocate an Array!T on the heap?
On Friday, 22 June 2012 at 10:19:13 UTC, Timon Gehr wrote:
On 06/22/2012 08:45 AM, Tobias Pankrath wrote:
import std.container;
struct A {};
void main()
{
Array!(A)* arr = new Array!(A);
}
yields
bug.d(7): Error: template std.container.Array!(A).Array.__ctor
does not
match any function template declaration
/usr/include/d/std/container.d(1625): Error: template
std.container.Array!(A).Array.__ctor(U) if
(isImplicitlyConvertible!(U,T)) cannot deduce template
function from
argument types !()()
This seems to work:
import std.container;
struct A {};
void main() {
auto arr = new Array!A(A.init);
}
Thanks.
Re: immutable ref foreach on values
On Friday, 22 June 2012 at 11:07:14 UTC, bearophile wrote:
Is this expected and good?
void main() {
int[] array = [1, 2];
foreach (ref const(int) x; array) {} // OK
foreach (ref immutable(int) x; array) {} // error
}
DMD 2.060alpha:
temp.d(4): Error: argument type mismatch, int to ref
immutable(int)
Thank you,
bye,
bearophile
I think it's good. In this special case, the compiler can see
that you can't change array behind his back. That seems not to be
true in general.
Re: immutable ref foreach on values
Tobias Pankrath: I think it's good. In this special case, the compiler can see that you can't change array behind his back. That seems not to be true in general. But aren't int implicitly castable to immutable? Bye, bearophile
Re: immutable ref foreach on values
On 22-Jun-12 16:16, bearophile wrote:
Tobias Pankrath:
I think it's good. In this special case, the compiler can see that you
can't change array behind his back. That seems not to be true in general.
But aren't int implicitly castable to immutable?
then every array is implicitly castable to tail immutable.
int[] array = [1, 2];
foreach (ref immutable(int) x; array) {
...
func(arr); // arr is mutable, thus func can change x
// so x can be at most const
}
--
Dmitry Olshansky
Re: immutable ref foreach on values
Dmitry Olshansky:
then every array is implicitly castable to tail immutable.
int[] array = [1, 2];
foreach (ref immutable(int) x; array) {
...
func(arr); // arr is mutable, thus func can change x
// so x can be at most const
}
I understand, thank you :-)
Bye,
bearophile
Re: Stack overflow
Am 22.06.2012 12:52, schrieb Namespace: On my machine it is the compiler that crashes = compiler bug. Presumably it is having trouble with the circular alias this. My first try to avoid this circular bug work with opDispatch. (As you can read here on my blog: http://blog.rswhite.de/archives/741) Now i had a new idea to save the Reference and call only these, it seems that it works fine and with a lot less code. (BTW, what is 'obj' in the invariant supposed to refer to?) Just for testing. ;) @Alex Rønne Petersen: Thanks a lot, i use assert(obj); that seems to serve the purpose. I hope in the next version alias this is more stable. I am wondering why you wanna have Objects which will never be null. Use a contract which checks for null and you're done (another benefit, it get's removed if you compile with -release). The only thing you gain from that is an Exception instead of a Segfault, where is the benefit, the app crashes in both cases and if you wanna handle those Exceptions, you can also check for null which is definitly faster and more readable (because it's clear to everyone). There were a few discussion about adding a NullPointerException, personally I wouldn't care if there was one, but implementing this behaviour with a library is the wrong way imo. This spreads inconsistency over D, some use it others don't, beginners will be confused. Btw. when developing, just start your program always with a debugger (shift+F9 instead of F9 for me, not a big deal), it will halt on a segfault and you can check why there is one.
Re: Stack overflow
If you have a null object you get an Access Violation without _any_ further information. That totally sucks. And in my opinion a small Ref!Type is more informative for others who use your code and you do not have to write assert(obj !is null); any time in any method again. And yes my program start's first with a debugger but, as i said, you will only get Access Violation and must debug by yourself to find the null object, if you avoid assert's.
Re: Stack overflow
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace rswhi...@googlemail.com wrote: If you have a null object you get an Access Violation without _any_ further information. That totally sucks. It doesn't have to be that way. A debug executable contains all sort of debugging information and a Just In Time debugger can attach and make use of it to show the cause of the access violation. Further, on both windows and various flavours of unix you can get a stack dump, which can be loaded into a debugger and used to locate the access violation. For the JIT case it's all automated on windows if/when you have visual studio installed, as soon as any application crashes a dialog appears and you can attach/debug. For the stack trace case I prefer using WinDbg where you can load the stack trace, point it at the PDB (produced even on a release build) and figure out where it crashed. If you have no PDB you can use a MAP file and the stack offsets to determine the crash location. Alternately, on windows you can call SetUnhandledExceptionFilter() to install a handler to catch any/all unhandled exceptions including access violations etc and then using the EXCEPTION_POINTERS ContextRecord member, walk the stack and produce your own stack trace at the instant the application crashes - I have some code which does this somewhere.. This last idea could automatically be built into exes produced by DMD so they all crash and output a stack trace (perhaps only if built in debug mode) and something similar can surely be done for unix. It's been a while since I did any serious development in D so maybe automatic stack traces already happen for some platforms? And in my opinion a small Ref!Type is more informative for others who use your code and you do not have to write assert(obj !is null); any time in any method again. It is nice to perform the assert/check once, then know from that point on it cannot be null ever again - saves multiple asserts/checks and makes the code cleaner in terms of having less noise. I think types which cannot be null are useful for that reason. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Stack overflow
Am 22.06.2012 16:55, schrieb Namespace: If you have a null object you get an Access Violation without _any_ further information. That totally sucks. I don't know what you're doing or which debugger you use, gdb shows me exactly what happened (line + stack + object). And in my opinion a small Ref!Type is more informative for others who use your code and you do not have to write assert(obj !is null); any time in any method again. I hope nobody will share code with Ref!Type, if they do people will relay on it and hey, all will do it, I don't need to check here, would be something different if it was not implemented by any library. And yes my program start's first with a debugger but, as i said, you will only get Access Violation and must debug by yourself to find the null object, if you avoid assert's. I have to debug nothing, as written above gdb sets automatically a breakpoint on a segmentation fault and shows me all the information I need.
Re: Stack overflow
On Friday, June 22, 2012 19:59:48 David wrote: Am 22.06.2012 16:55, schrieb Namespace: If you have a null object you get an Access Violation without _any_ further information. That totally sucks. I don't know what you're doing or which debugger you use, gdb shows me exactly what happened (line + stack + object). Well, he's clearly on Windows if he's seeing an access violation, but regardless, there are plenty of developers who have no clue that you can get any information from a segfault or access violation. Personally, I'd been programming in C/C++ for years before I found out it was possible. And it can be _very_ frustrating to get a segfault when all that tells you is that you're programming is crashing somewhere, somehow. Fortunately, debuggers like gdb make it possible to figure out what happened in great detail (either by examining a core dump or running the program in a debugger), but my guess is that Namespace just doesn't know how to do that or that it's even possible - hence his frustration with not getting any information. - Jonathan M Davis
Re: Writing .di files
I'm sorry, what I meant was how to interface to C code. Sorry for writing it in a bad way. Do I just declare the C code as extern and then link together with the C .lib/.o/.so file? (I'm in Ubuntu) What about the stuff that is in header files?
Re: Getting started with threads in D
On Sunday, 17 June 2012 at 07:23:38 UTC, Russel Winder wrote: On Sun, 2012-06-17 at 03:15 +0200, Henrik Valter Vogelius Hansson wrote: Hi again! I have looked around a little with what D offers but don't know really what I should use since D offers several ways to use threads. Some more high level than others. Don't really also know which one would be suitable for me. My take on this is that as soon as an applications programmer talks about using threads in their program, they have admitted they are working at the wrong level. Applications programmers do not manage their control stacks, applications programmers do not manage their heaps, why on earth manage your threads. Threads are an implementation resource best managed by an abstraction. Using processes and message passing (over a thread pool, as you are heading towards in comments below) has proven over the last 30+ years to be the only scalable way of managing parallelism, so use it as a concurrency technique as well and get parallelism as near as for free as it is possible to get. Ancient models and techniques such as actors, dataflow, CSP, data parallelism are making a resurgence exactly because explicit shared memory multi-threading is an inappropriate technique. It has just taken the world 15+ years to appreciate this. A little background could help. I am a game developer and during my semester I want to experiment with making games in D. I use threads to separate some tasks that can easily work in parallel with each other. The most common being a Logic/Graphics separation. But as development progresses I usually add more threads like inside graphics I can end up with 2 or 3 more threads. I can only repeat the above: don't think in terms of threads and shared memory, think in terms of processes and messages passed between them. I want to avoid Amdahl's law as much as possible and have as small synchronization nodes. The data exchange should be as basic as possible but still have room for improvements and future additions. Isn't the current hypothesis that you can't avoid Amdahl's Law? If what you mean is that you want to ensure you have an embarrassingly parallel solution so that speed up is linear that seems entirely reasonable, but then D has a play in this game with the std.parallelism module. It uses the term task rather than process or thread to try and enforce an algorithm-focused view. cf. http://dlang.org/phobos/std_parallelism.html The Concurrency library looked very promising but felt like the synchronization wouldn't be that nice but it would provide a random-access to the data in your code. Correct me of course if I am wrong. Is there a good thread pool system that could be used? Does that system also handle solving dependencies in the work-flow? This is what we use at my work more or less. What makes you say synchronization is not that nice? Random access, data, threads and parallelism in the same paragraph raises a red flag of warning! std.concurrency is a realization of actors so there is effectively a variety of thread pool involved. std.parallelism has task pools explicitly. In worst case scenario I will just use the basic thread class and implement my own system above that. Then there is the question, is there any pitfalls in the current library that I should be aware of? I am sure D's current offerings are not perfect but they do represent a good part of the right direction to be travelling. What is missing is a module for dataflow processing(*) and one for CSP. Sadly I haven't had time to get stuck into doing an implementation as I had originally planned 18 months or so ago: most of my time is now in the Python and Groovy arena as that is where the income comes from. cf. GPars (http://gpars.codehaus.org) and Python-CSP – though the latter has stopped moving due to planning a whole new Python framework for concurrency and parallelism. (*) People who talk about you can implement dataflow with actors and vice versa miss the point about provision of appropriate abstractions with appropriate performance characteristics. Aight been reading a lot now about it. I'm interested in the TaskPool but there is a problem and also why I have to think about threads. OpenGL/DirectX contexts are only valid for one thread at a time. And with the task pool I can't control what thread to be used with the specified task right? At least from what I could find I couldn't. So that's out of the question. The concurrency library is... I don't know. I most usually do a very fast synchronization swap(just swap two pointers) while the concurrency library seems like it would halt both threads for a longer time. Or am I viewing this from the wrong direction? Should I do it like lazy evaluation maybe? If you need code examples of what I am talking about I can give you that. Though I don't know the code-tag for this message board. I will still use the task
