Re: Early std.crypto
On 11/4/2011 7:52 PM, bcs wrote: tl;dr; It mentions "cache-based, timing, and other side channel attacks". Unless you can explain to me what those are, in painful detail, I don't think we should trust you to avoid them. Get a good vetted C implementation and wrap it with a nice D API and call it a day. You've got a good point. While I'd like to see native D implementations, crypto security is such a big issue we'd probably be better off with your suggestion.
Re: Early std.crypto
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote: bcs wrote: Are you re-implementing the function kernels your self or are you using an existing implementation? Given what I've heard about things like side-channel attacks using processing times to recover keys, I'd rather not see Phobos use anything written by less than the best expert available. Until now, I implemented some hash functions. There are no branching instructions in their transform() routines, so theoretically processing time is independent of the function input. From my very incomplete memory I found the source I was looking for (I googled for "aes interperative dance") here http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html Look for "Foot-Shooting Prevention Agreement" in one of the images ~20-25% of the way down. tl;dr; It mentions "cache-based, timing, and other side channel attacks". Unless you can explain to me what those are, in painful detail, I don't think we should trust you to avoid them. Get a good vetted C implementation and wrap it with a nice D API and call it a day.
Re: [OT] First time I've laughed while looking at DMD commits
On 04-11-2011 20:44, simendsjo wrote: "Nobody tosses a dwarf!" https://github.com/D-Programming-Language/dmd/commit/65dc204cace38d68f3d62837e643026d44c7f22e When I saw the email on dmd-internals, I had to reread the subject a couple of times. :) - Alex
Re: Native D MySQL Driver
On Nov 4, 2011, at 12:05 PM, Steve Teale wrote: > On Fri, 04 Nov 2011 10:19:23 -0700, bls wrote: > >> On 11/04/2011 09:25 AM, Steve Teale wrote: >>> I don't think you need to worry >>> about changes while stepping through rows. >> > > As in don't worry about something over which you have no control! > >> However, there are always many ways to skin a cat. PostgreSQL, Firebird, >> MSSQL Server (not sure about MySQL) enable you to trigger server side >> events. >> Means the database server fires an update event (say employee deleted >> event) and a D function living in a secondary thread will catch this >> event and inform all interested parties (subscribers**) to refresh their >> RowSet. (and of course the UI) >> >> Beside, this is the way we create mission critical,db-centric realtime >> apps. works fine. >> My 2 cents. > > Bjoern > > There's not a hint of that in the MySQL protocol. It'a purely command/ > response. The commands are: ... > I don't see a 'let me know when something happens' command here. There is > also no trace of it in the C API. Unless something has changed in the last few years, the way to do this in MSSQL is via a plugin in the SQL server itself. Back in the days of yore this was via extended stored procedures, which were loaded as a DLL by the SQL server, but I think more recent iterations can call COM or .NET code or something like that as well. In short, the event notification isn't typically done via a back-feed through a client connection. Do any modern DBMSes have pub/sub functionality like this?
[OT] First time I've laughed while looking at DMD commits
"Nobody tosses a dwarf!" https://github.com/D-Programming-Language/dmd/commit/65dc204cace38d68f3d62837e643026d44c7f22e
Re: Native D MySQL Driver
On Fri, 04 Nov 2011 16:58:23 +, Dejan Lekic wrote: > > It is all right - you asked for opinions - you got it. :) > > If I wanted to do it in chunks, I would code that myself, and execute > something like "SELECT * FROM few_bil_rows_table LIMIT offset, > rowCount". That's close to my point. Someone wanting the whole shebang would not have any particular difficulty in using the interfaces I'm proposing, without explicitly asking for chunks. The server sends the whole thing, all I'm doing for the complete result set case is to aggregate all - or some restricted number - of the rows. I don't see any efficiency penalty for a user who chooses to aggregate the same incoming stream of rows in some other way. There's no work for her to do - they're already decoded. But what is going to be the most common aggregation requirement? I'm thinking it is a size_t array of rows. Steve
Re: Native D MySQL Driver
On 11/04/2011 12:05 PM, Steve Teale wrote: Your point is in fact in support of what I was saying. Why the hell allow the user to get 2^^64 rows when they're going to be out of date before they've been got together! Exactly. That's why we prefer server side events and refresh the UI/RowSet just in case of relevance. Another point is that you can't load them (without chunking) into a table control/widget. So I would say, don't care about the 2^^64 row. how we use server side events.. in case that this is interesting.. A window subscribes to an server-side event publisher, The publisher informs all subscribers (Windows) The window clears and refills the row-set and finally display the data. closing the window means unregister from publisher. bla, bla Bjoern
Re: Development of language specification (was typedef alive and well?)
On 04-11-2011 17:10, Martin Nowak wrote: Moved to an extra thread, so it won't get lost. I propose the following process using the language specifications at github:d-programming-language.org. - The language specifications are made version specific (e.g. 2.6, partly handled by tags already). - Branches are created for the next 2(?) minor versions ahead of the current release cycle. Another one is created for the next major version. - The website should have links to specifications for different versions which are build from the corresponding tags/branches. - We adopt a pull based development for the language specification similar to that for phobos (review queue, review manager, voting). - Specs are lined with acceptance tests. Ideally this would be the code examples. - The compiler strives to fulfill the specs on corresponding versions. - Specs are added to the autotester. Not sure if github:d-programming-language.org can handle all this appropriately, but it seems worth a try. As a first test case someone could salvage the abbreviated delegate syntax (a => a+2). martin I hate to sound like a troll, but what we have right now hardly qualifies as a language reference. A *real* specification would be much more complicated and in-depth. I *do* think we need to develop a better, more formal specification, but this will obviously require efforts from all the people involved in the development and evolution of D. - Alex
Re: Native D MySQL Driver
On Fri, 04 Nov 2011 10:19:23 -0700, bls wrote: > On 11/04/2011 09:25 AM, Steve Teale wrote: >> I don't think you need to worry >> about changes while stepping through rows. > As in don't worry about something over which you have no control! > However, there are always many ways to skin a cat. PostgreSQL, Firebird, > MSSQL Server (not sure about MySQL) enable you to trigger server side > events. > Means the database server fires an update event (say employee deleted > event) and a D function living in a secondary thread will catch this > event and inform all interested parties (subscribers**) to refresh their > RowSet. (and of course the UI) > > Beside, this is the way we create mission critical,db-centric realtime > apps. works fine. > My 2 cents. Bjoern There's not a hint of that in the MySQL protocol. It'a purely command/ response. The commands are: 0x00 COM_SLEEP (none, this is an internal thread state) 0x01 COM_QUITmysql_close 0x02 COM_INIT_DB mysql_select_db 0x03 COM_QUERY mysql_real_query 0x04 COM_FIELD_LIST mysql_list_fields 0x05 COM_CREATE_DB mysql_create_db (deprecated) 0x06 COM_DROP_DB mysql_drop_db (deprecated) 0x07 COM_REFRESH mysql_refresh 0x08 COM_SHUTDOWNmysql_shutdown 0x09 COM_STATISTICS mysql_stat 0x0a COM_PROCESS_INFOmysql_list_processes 0x0b COM_CONNECT (none, this is an internal thread state) 0x0c COM_PROCESS_KILLmysql_kill 0x0d COM_DEBUG mysql_dump_debug_info 0x0e COM_PINGmysql_ping 0x0f COM_TIME(none, this is an internal thread state) 0x10 COM_DELAYED_INSERT (none, this is an internal thread state) 0x11 COM_CHANGE_USER mysql_change_user 0x12 COM_BINLOG_DUMP sent by the slave IO thread to request a binlog 0x13 COM_TABLE_DUMP LOAD TABLE ... FROM MASTER (deprecated) 0x14 COM_CONNECT_OUT (none, this is an internal thread state) 0x15 COM_REGISTER_SLAVE sent by the slave to register ...) 0x16 COM_STMT_PREPAREmysql_stmt_prepare 0x17 COM_STMT_EXECUTEmysql_stmt_execute 0x18 COM_STMT_SEND_LONG_DATA mysql_stmt_send_long_data 0x19 COM_STMT_CLOSE mysql_stmt_close 0x1a COM_STMT_RESET mysql_stmt_reset 0x1b COM_SET_OPTION mysql_set_server_option 0x1c COM_STMT_FETCH mysql_stmt_fetch I don't see a 'let me know when something happens' command here. There is also no trace of it in the C API. Maybe it's unsophisticated, but it's popular, and that's the beast I'm dealing with. Your point is in fact in support of what I was saying. Why the hell allow the user to get 2^^64 rows when they're going to be out of date before they've been got together! Steve
DSQLite a libraryri using sqlite
Dear, i have wrote a litlle lib using etc.c.sqlite3 for use sqlite in D Now it is most easier to use sqlite in D than directly use C interface I have put here : https://github.com/bioinfornatics/DSQLite/blob/master/examples/test_sql.d an example of use I need now comment my code any help or feed back is welcome kind regards
Re: Segfault when using SysTime
On 04.11.2011 18:27, Jonathan M Davis wrote: On Friday, November 04, 2011 06:07 bearophile wrote: Jonathan M Davis: and since CTFE can't handle classes - let alone one which is initialized at compile time and then used at runtime I think CTFE will handle classes in the next DMD version (and in the current GitHub one). But it's not just a question of handling classes. It has to handle the case where the class persists during runtime. From what Don has said in the past, I'm pretty sure that supporting classes in CTFE is going to translate to being able to use functions that use classes but that none of the classes created will be able to be assigned to any variables which persist beyond compilation. It needs to become possible to do something like static immutable _localTime = new immutable(LocalTime)(); For SysTime.init to be valid, LocalTime's instance must be created at compile time and persist beyond compilation, and then SysTime's _timezone member variable needs to be initialized to it - which would also persist beyond compilation. If Don manages to make that work, that's fantastic, but there's a definite difference between being able to use classes with CTFE and initialize member and static variables with classes using CTFE, and it is my understanding that that we're only getting to use classes in CTFE, not persist them. But maybe we're lucky, and I'm wrong about that. - Jonathan M Davis That's right. The next release will support classes (and exceptions) in CTFE, but as you say, it cannot pass them to run time. This is an issue of the glue layer in the compiler. I do know how it could be done. It will happen eventually, but not soon.
Re: core.cpuid
On Friday, November 04, 2011 10:39 Dejan Lekic wrote:
> Jonathan M Davis wrote:
> > And why not? Thread is in core. So are other modules that it's perfectly
>
> - Mostly because You may end-up writing non-portable code unless you are
> realy careful (and you must be if you use core modules! ;). It is similar
> to the asm{} block - you should not use it at all unless you know what you
> are doing... Does that make sense?
Plenty of core is portable. True, very little in Phobos is non-portable, so
there's less risk of portability issues with Phobos, but much of druntime is
quite portable - Thread being one such example. It's primarily the C
declarations which aren't necessarily portable. Most of the D code is.
Now, it _is_ ultimately to the programmer to be smart about what they're
doing, and more stuff in druntime is non-portable than in Phobos, but it's
generally pretty clear about what's portable and what isn't. I really don't
think that there's any need to tell people to stay away from core. If
anything, they'll stay often away from it simply because much of its
functionality is not directly necessary (if necessary at all) in your average
program. But if you need it, there's nothing wrong with using it, and on the
whole, portability isn't a huge issue.
- Jonathan M Davis
Re: core.cpuid
On 04.11.2011 18:27, Jonathan M Davis wrote: On Friday, November 04, 2011 08:11 Dejan Lekic wrote: Manu wrote: Seems like a horrible assumption to make when inventing a systems programming language that intends to go head to head with C/C++ :) FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. developers rarely use cpuid.h directly). You should not (in practice) use "core" modules anyway. And why not? Thread is in core. So are other modules that it's perfectly normal and acceptable to use. There's nothing wrong with using core modules. Many of them are _intended_ to be used. Stuff generally ends up in core because the D runtime needs it, not because it's something that the common programmer shouldn't be using. That's largely true, but I would agree with Manu that you shouldn't be using core very often. By its nature of being close to the runtime, it's typically low-level stuff, and so it's only your low-level code which should be using it. Probably there is some stuff in there which should be moved out of core, or possibly with a safer wrapper in std. I'm particularly thinking of core.bitop, which currently has a mixture of safe and subtly dangerous functions, and only a small part of it is actually required by the runtime.
Re: core.cpuid
Jonathan M Davis wrote:
>
> And why not? Thread is in core. So are other modules that it's perfectly
- Mostly because You may end-up writing non-portable code unless you are
realy careful (and you must be if you use core modules! ;). It is similar to
the asm{} block - you should not use it at all unless you know what you are
doing... Does that make sense?
Re: Segfault when using SysTime
On Friday, November 04, 2011 06:07 bearophile wrote: > Jonathan M Davis: > > and since CTFE can't handle classes - let alone one which is > > initialized at compile time and then used at runtime > > I think CTFE will handle classes in the next DMD version (and in the > current GitHub one). But it's not just a question of handling classes. It has to handle the case where the class persists during runtime. From what Don has said in the past, I'm pretty sure that supporting classes in CTFE is going to translate to being able to use functions that use classes but that none of the classes created will be able to be assigned to any variables which persist beyond compilation. It needs to become possible to do something like static immutable _localTime = new immutable(LocalTime)(); For SysTime.init to be valid, LocalTime's instance must be created at compile time and persist beyond compilation, and then SysTime's _timezone member variable needs to be initialized to it - which would also persist beyond compilation. If Don manages to make that work, that's fantastic, but there's a definite difference between being able to use classes with CTFE and initialize member and static variables with classes using CTFE, and it is my understanding that that we're only getting to use classes in CTFE, not persist them. But maybe we're lucky, and I'm wrong about that. - Jonathan M Davis
Re: core.cpuid
On Friday, November 04, 2011 08:11 Dejan Lekic wrote: > Manu wrote: > > Seems like a horrible assumption to make when inventing a systems > > programming language that intends to go head to head with C/C++ :) > > FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. > developers rarely use cpuid.h directly). You should not (in practice) use > "core" modules anyway. And why not? Thread is in core. So are other modules that it's perfectly normal and acceptable to use. There's nothing wrong with using core modules. Many of them are _intended_ to be used. Stuff generally ends up in core because the D runtime needs it, not because it's something that the common programmer shouldn't be using. - Jonathan M Davis
Re: Development of language specification (was typedef alive and well?)
Le 04/11/2011 17:10, Martin Nowak a écrit : Moved to an extra thread, so it won't get lost. I propose the following process using the language specifications at github:d-programming-language.org. - The language specifications are made version specific (e.g. 2.6, partly handled by tags already). - Branches are created for the next 2(?) minor versions ahead of the current release cycle. Another one is created for the next major version. - The website should have links to specifications for different versions which are build from the corresponding tags/branches. - We adopt a pull based development for the language specification similar to that for phobos (review queue, review manager, voting). - Specs are lined with acceptance tests. Ideally this would be the code examples. - The compiler strives to fulfill the specs on corresponding versions. - Specs are added to the autotester. Not sure if github:d-programming-language.org can handle all this appropriately, but it seems worth a try. As a first test case someone could salvage the abbreviated delegate syntax (a => a+2). martin I would love that ! And I'm pretty sure I'm not the only one. D definitively needs more specs.
Re: Native D MySQL Driver
On 11/04/2011 09:25 AM, Steve Teale wrote: I don't think you need to worry about changes while stepping through rows. That's questionable. Consider Stock Market quotes. Some lib designers, for instance. libpgxx (C++ PostgreSQL) have a different view.. let me quote : *With conventional database APIs, you issue commands and queries to a database session or connection, and optionally create the occasional transaction. In libpqxx you start with a connection, but you do all your SQL work in transactions that you open in your connection. You commit each transaction when it's complete; if you don't, all changes made inside the transaction get rolled back.* However, there are always many ways to skin a cat. PostgreSQL, Firebird, MSSQL Server (not sure about MySQL) enable you to trigger server side events. Means the database server fires an update event (say employee deleted event) and a D function living in a secondary thread will catch this event and inform all interested parties (subscribers**) to refresh their RowSet. (and of course the UI) Beside, this is the way we create mission critical,db-centric realtime apps. works fine. My 2 cents. Bjoern ** Publisher/Subscriber pattern.
Re: Native D MySQL Driver
Steve Teale wrote: > > Don't get me wrong. I was not asking if it should be possible to get a > complete result set, only if we needed to support sets with 2^^64 rows on > a 32 bit system. Personally I think that is close to stupid - SQL is > supposed to allow you to select the rows you want - not to make you do > that on the client side. It is all right - you asked for opinions - you got it. :) I am also writing a native D database driver, for the Ingres RDBMS. It is basically an implementation of the all Ingres DAMP protocols (lvl 1 to 7, the latest one). There you really need to make a cursor if you really want to do something you describe above. However, Ingres RDBMS will send you the result in messages (ie. chunks). But it really does not matter if it sends the result in chunks or if it streams the whole thing immediately (i would actually prefer Ingres does that, it would make some things easier). If I as a developer execute "SELECT * FROM few_bil_rows_table" I am *aware* of the consequence, but I still want *ALL ROWS*, because, say, I am doing an OLAP query, and I want to generate a huge report ASAP. :) Ask any BI expert, and they will tell you that 2^64 result set is nothing! :) Yes, hands down, if one deals with 2^64 result sets, that person will most likely *not* use MySQL/MariaDB but something more suitable, like Ingres (now Actian) VectorWise, and similar. If I wanted to do it in chunks, I would code that myself, and execute something like "SELECT * FROM few_bil_rows_table LIMIT offset, rowCount".
Re: Native D MySQL Driver
On Fri, 04 Nov 2011 15:04:39 +, Dejan Lekic wrote: > > Yes it is. It is a common practice to get the whole thing rather than to > take it in chunks. (Atomically so to speak) 1) The first thing that > comes to mind is efficiency. 2) The second is - you remove the > complexity (you will have to deal with various chunks). > 3) The third reason, and the most important one, is the high possibility > that your result set is going to change while you receive chunks. So, if > you received it in chunks, it is possible that the overall data may be > INCONSISTENT. So if you really wanted it to be done in chunks then you > would have to make a snapshot of the result set on the database side, > while behind the scenes those records keep being updated... Dejan, Don't get me wrong. I was not asking if it should be possible to get a complete result set, only if we needed to support sets with 2^^64 rows on a 32 bit system. Personally I think that is close to stupid - SQL is supposed to allow you to select the rows you want - not to make you do that on the client side. I will also support the row by row approach, because there are users who prefer that. With the MySQL protocol, I don't think you need to worry about changes while stepping through rows. It's very basic - the server sends the whole result set over the wire in response to a query. Whether you read them all first or deal with them one at a time is academic. You still have to read them all before you can do anything else on that thread. So what you get is a snapshot either way. Steve
Development of language specification (was typedef alive and well?)
Moved to an extra thread, so it won't get lost. I propose the following process using the language specifications at github:d-programming-language.org. - The language specifications are made version specific (e.g. 2.6, partly handled by tags already). - Branches are created for the next 2(?) minor versions ahead of the current release cycle. Another one is created for the next major version. - The website should have links to specifications for different versions which are build from the corresponding tags/branches. - We adopt a pull based development for the language specification similar to that for phobos (review queue, review manager, voting). - Specs are lined with acceptance tests. Ideally this would be the code examples. - The compiler strives to fulfill the specs on corresponding versions. - Specs are added to the autotester. Not sure if github:d-programming-language.org can handle all this appropriately, but it seems worth a try. As a first test case someone could salvage the abbreviated delegate syntax (a => a+2). martin
Re: Segfault when using SysTime
knommad Wrote: > structures that have SysTime elements within them. I hadn't always been > ensuring that this member was initialised properly (not always important for > the task), but when I wanted to toString() the members - I had a silent > death. try std.conv.text, it may handle null pointers.
Re: core.cpuid
Manu wrote: > Seems like a horrible assumption to make when inventing a systems > programming language that intends to go head to head with C/C++ :) > FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. developers rarely use cpuid.h directly). You should not (in practice) use "core" modules anyway.
Re: Native D MySQL Driver
Steve Teale wrote: > > I also have a question. MySQL potentially produces result sets of up to > 64 bit size - rows. The MySQL client theoretically copes with these by > storing a result set as a doubly linked list, and there's nothing to stop > me doing the same. But is it necessary? Yes it is. It is a common practice to get the whole thing rather than to take it in chunks. (Atomically so to speak) 1) The first thing that comes to mind is efficiency. 2) The second is - you remove the complexity (you will have to deal with various chunks). 3) The third reason, and the most important one, is the high possibility that your result set is going to change while you receive chunks. So, if you received it in chunks, it is possible that the overall data may be INCONSISTENT. So if you really wanted it to be done in chunks then you would have to make a snapshot of the result set on the database side, while behind the scenes those records keep being updated...
Re: foreach(r; requests) { r.concider(); }
Actually, i didn't think of it before. Good point.
This is not the most efficient way to iterate over a range in a custom way.
On Fri, Nov 4, 2011 at 6:34 PM, Steven Schveighoffer
wrote:
> On Fri, 04 Nov 2011 09:01:11 -0400, Christophe
> wrote:
>
>> "Steven Schveighoffer" , dans le message (digitalmars.D:146563), a
>> écrit :
>>
>> The foreach delegate syntax already allow you to have parametrized
>> iteration over a structure !
>>
>> Actually, the delegate do not have to be returned by the & operator, it
>> can be returned by a function. It's a bit awkward first, but then it's
>> easy to use:
>>
>> struct Iterable
>> {
>> int delegate(int delegate(ref int)) inReverse()
>> {
>> return ()
>> {
>> int result = 0;
>> foreach(int i; 0..100)
>> {
>> auto t = 99-i;
>> if((result = dg(t)) != 0) break;
>> }
>> return result;
>> }
>> }
>>
>> int delegate(int delegate(ref int)) byStep(int step)
>> {
>> return()
>> {
>> int result = 0;
>> foreach(int i; iota(0, 100, step))
>> {
>> auto t = i;
>> if((result = dg(t)) != 0) break;
>> }
>> return result;
>> }
>> }
>> }
>>
>>
>> int main()
>> {
>> Iterable it;
>> foreach (i; it.inReverse) writeln(i);
>> foreach (i; it.byStep(2)) writeln(i);
>> }
>>
>>
>> There is no need to add a special syntax to do what you want !
>>
>> Maybe there should be a bit more documentation about this.
>
> I'll point out first that this solution allocates a closure on the heap --
> not necessarily the most efficient solution.
>
> Second of all, this seems like a *lot* of trouble to go through just to call
> a function (yes, that's all you're doing). The delegate returned is called
> *once* and then thrown away.
>
> I'd much rather the language just support the most straightforward solution
> (calling a function with the given parameters).
>
> -Steve
>
Re: foreach(r; requests) { r.concider(); }
On Fri, 04 Nov 2011 09:01:11 -0400, Christophe
wrote:
"Steven Schveighoffer" , dans le message (digitalmars.D:146563), a
écrit :
The foreach delegate syntax already allow you to have parametrized
iteration over a structure !
Actually, the delegate do not have to be returned by the & operator, it
can be returned by a function. It's a bit awkward first, but then it's
easy to use:
struct Iterable
{
int delegate(int delegate(ref int)) inReverse()
{
return ()
{
int result = 0;
foreach(int i; 0..100)
{
auto t = 99-i;
if((result = dg(t)) != 0) break;
}
return result;
}
}
int delegate(int delegate(ref int)) byStep(int step)
{
return()
{
int result = 0;
foreach(int i; iota(0, 100, step))
{
auto t = i;
if((result = dg(t)) != 0) break;
}
return result;
}
}
}
int main()
{
Iterable it;
foreach (i; it.inReverse) writeln(i);
foreach (i; it.byStep(2)) writeln(i);
}
There is no need to add a special syntax to do what you want !
Maybe there should be a bit more documentation about this.
I'll point out first that this solution allocates a closure on the heap --
not necessarily the most efficient solution.
Second of all, this seems like a *lot* of trouble to go through just to
call a function (yes, that's all you're doing). The delegate returned is
called *once* and then thrown away.
I'd much rather the language just support the most straightforward
solution (calling a function with the given parameters).
-Steve
Re: foreach(r; requests) { r.concider(); }
This is perfect! No need for extra syntax :-)
Thanks a lot! :-)
On Fri, Nov 4, 2011 at 5:01 PM, Christophe wrote:
> "Steven Schveighoffer" , dans le message (digitalmars.D:146563), a
> écrit :
>
> The foreach delegate syntax already allow you to have parametrized
> iteration over a structure !
>
> Actually, the delegate do not have to be returned by the & operator, it
> can be returned by a function. It's a bit awkward first, but then it's
> easy to use:
>
> struct Iterable
> {
> int delegate(int delegate(ref int)) inReverse()
> {
> return ()
> {
> int result = 0;
> foreach(int i; 0..100)
> {
> auto t = 99-i;
> if((result = dg(t)) != 0) break;
> }
> return result;
> }
> }
>
> int delegate(int delegate(ref int)) byStep(int step)
> {
> return()
> {
> int result = 0;
> foreach(int i; iota(0, 100, step))
> {
> auto t = i;
> if((result = dg(t)) != 0) break;
> }
> return result;
> }
> }
> }
>
>
> int main()
> {
> Iterable it;
> foreach (i; it.inReverse) writeln(i);
> foreach (i; it.byStep(2)) writeln(i);
> }
>
>
> There is no need to add a special syntax to do what you want !
>
> Maybe there should be a bit more documentation about this.
>
Re: Segfault when using SysTime
Jonathan M Davis: > and since CTFE can't handle classes - let alone one which is > initialized at compile time and then used at runtime I think CTFE will handle classes in the next DMD version (and in the current GitHub one). Bye, bearophile
Re: foreach(r; requests) { r.concider(); }
"Steven Schveighoffer" , dans le message (digitalmars.D:146563), a
écrit :
The foreach delegate syntax already allow you to have parametrized
iteration over a structure !
Actually, the delegate do not have to be returned by the & operator, it
can be returned by a function. It's a bit awkward first, but then it's
easy to use:
struct Iterable
{
int delegate(int delegate(ref int)) inReverse()
{
return ()
{
int result = 0;
foreach(int i; 0..100)
{
auto t = 99-i;
if((result = dg(t)) != 0) break;
}
return result;
}
}
int delegate(int delegate(ref int)) byStep(int step)
{
return()
{
int result = 0;
foreach(int i; iota(0, 100, step))
{
auto t = i;
if((result = dg(t)) != 0) break;
}
return result;
}
}
}
int main()
{
Iterable it;
foreach (i; it.inReverse) writeln(i);
foreach (i; it.byStep(2)) writeln(i);
}
There is no need to add a special syntax to do what you want !
Maybe there should be a bit more documentation about this.
Re: Native D MySQL Driver
On Fri, 04 Nov 2011 12:13:34 +0100, Piotr Szturmaj wrote: > > Why not return a range, that will fetch next row when needed? popFront() > will call socket's recv, parse and then store that row for the front() > calls. This may be internally buffered to 100 rows or so. > > Example: https://github.com/pszturmaj/ddb/blob/master/postgres.d#L2145 I use a range in both cases, getting the whole result set or fetching a row at a time. It's just the whole result set case I'm wondering about. Steve
Re: Early std.crypto
bcs wrote: Are you re-implementing the function kernels your self or are you using an existing implementation? Given what I've heard about things like side-channel attacks using processing times to recover keys, I'd rather not see Phobos use anything written by less than the best expert available. Until now, I implemented some hash functions. There are no branching instructions in their transform() routines, so theoretically processing time is independent of the function input.
Re: Native D MySQL Driver
I also have a question. MySQL potentially produces result sets of up to 64 bit size - rows. The MySQL client theoretically copes with these by storing a result set as a doubly linked list, and there's nothing to stop me doing the same. But is it necessary? Why not return a range, that will fetch next row when needed? popFront() will call socket's recv, parse and then store that row for the front() calls. This may be internally buffered to 100 rows or so. Example: https://github.com/pszturmaj/ddb/blob/master/postgres.d#L2145
Re: Native D MySQL Driver
On 11/03/2011 10:15 PM, Steve Teale wrote: 2) No Windows Named Pipe support that I've noticed. Isn't it part of std.windows ? Named piped support is part of kernel32.dll maybe this link helps > http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx 3) No SHA1 digest support The is a MIT X11 licensed lib on dsource called dcryot. A public domain C lib is available under > http://libtom.org/?page=features&newsitems=5&whatfile=crypt and finally (like it) a Javascript snippet, no licence information! > http://www.webtoolkit.info/javascript-sha1.html HTH Bjoern
Re: Segfault when using SysTime
On Friday, November 04, 2011 19:37:56 knommad wrote: > Hi, > Thanks for the answer (nicely written article btw). > > I actually found this issue via a problematic path. I'm writing a (multi- > threaded) application in D (within the company I work for), and have > structures that have SysTime elements within them. I hadn't always been > ensuring that this member was initialised properly (not always important for > the task), but when I wanted to toString() the members - I had a silent > death. > > The silent death was not a segfault, and gdb considered the application to > have exited normally. This was not easy to nail down ! (a nice segfault > would have been helpful at that point:) > > I guess I'm also expecting (hoping ?) that stray pointer-like behaviours in > D to be few and far between (as opposed to the float.NAN issue). I'm happy > to accept that I may be naive here, however. > > Keep up the good work ! I would have expected a segfault, since that's what normally happens when dereferencing a null reference, so I don't know what the issue there is. If you could come up with a small enough test case, it may be worth looking into. I'd love for SysTime.init's time zone to be LocalTime, but that's just not possible at this point, so we're pretty much stuck with a null reference. But the lack of segfault is still weird. - Jonathan M Davis
Re: Segfault when using SysTime
Jonathan M Davis wrote:
> On Friday, November 04, 2011 18:53:28 knommad wrote:
>> Hi,
>>
>> (I'm not sure whether I should be posting these here...apologies if this
>> is inappropriate).
>>
>>
>> Test case: (test.d)
>> import std.datetime;
>> import std.stdio;
>>
>>
>> void main()
>> {
>> // SysTime is a struct that should be default initialised
>> SysTime unInitialisedTime;
>>
>> // Will segfault on this next line...
>> writeln("Time is: ", unInitialisedTime );
>>
>> writeln("ending now...");
>>
>> }
>>
>> Compiled with dmd 2.056: dmd -wi -oftest test.d.
>>
>> Result:
>> Segmentation Fault.
>>
>> I did attempt to delve into the intricacies of the std.datetime library,
>> but understanding the techniques used is currently beyond my skill level.
>>
>> Obviously, something is not being initialised properly?
>
> Similar to how float.init is not a valid value (float.NAN), SysTime.init
> is not a valid value. Aside from arguments over whether a struct's init
> value should be a value intended to be used or not, SysTime has a member
> which is a class - TimeZone - and since CTFE can't handle classes - let
> alone one which is initialized at compile time and then used at runtime -
> SysTime.init _cannot_ have a valid TimeZone and therofere SysTime.init
> cannot be valid (unless we were to introduce the extra overhead of
> constantly checking that the TimeZone isn't null and setting it to
> LocalTime if it is, which is unacceptable IMHO). And since, SysTime.init
> isn't valid, you _must_ initialize a SysTime if you want to avoid
> segfaults.
>
> If you want to know more about std.datetime, I suggest that you read this
> article:
>
> http://d-programming-language.org/intro-to-datetime.html
>
> - Jonathan M Davis
Hi,
Thanks for the answer (nicely written article btw).
I actually found this issue via a problematic path. I'm writing a (multi-
threaded) application in D (within the company I work for), and have
structures that have SysTime elements within them. I hadn't always been
ensuring that this member was initialised properly (not always important for
the task), but when I wanted to toString() the members - I had a silent
death.
The silent death was not a segfault, and gdb considered the application to
have exited normally. This was not easy to nail down ! (a nice segfault
would have been helpful at that point:)
I guess I'm also expecting (hoping ?) that stray pointer-like behaviours in
D to be few and far between (as opposed to the float.NAN issue). I'm happy
to accept that I may be naive here, however.
Keep up the good work !
regards,
ted
--
When the student is ready, the teacher will appear
-- Buddhist Proverb
Re: Segfault when using SysTime
On Friday, November 04, 2011 18:53:28 knommad wrote:
> Hi,
>
> (I'm not sure whether I should be posting these here...apologies if this is
> inappropriate).
>
>
> Test case: (test.d)
> import std.datetime;
> import std.stdio;
>
>
> void main()
> {
> // SysTime is a struct that should be default initialised
> SysTime unInitialisedTime;
>
> // Will segfault on this next line...
> writeln("Time is: ", unInitialisedTime );
>
> writeln("ending now...");
>
> }
>
> Compiled with dmd 2.056: dmd -wi -oftest test.d.
>
> Result:
> Segmentation Fault.
>
> I did attempt to delve into the intricacies of the std.datetime library, but
> understanding the techniques used is currently beyond my skill level.
>
> Obviously, something is not being initialised properly?
Similar to how float.init is not a valid value (float.NAN), SysTime.init is not
a valid value. Aside from arguments over whether a struct's init value should
be a value intended to be used or not, SysTime has a member which is a class -
TimeZone - and since CTFE can't handle classes - let alone one which is
initialized at compile time and then used at runtime - SysTime.init _cannot_
have a valid TimeZone and therofere SysTime.init cannot be valid (unless we
were to introduce the extra overhead of constantly checking that the TimeZone
isn't null and setting it to LocalTime if it is, which is unacceptable IMHO).
And since, SysTime.init isn't valid, you _must_ initialize a SysTime if you
want to avoid segfaults.
If you want to know more about std.datetime, I suggest that you read this
article:
http://d-programming-language.org/intro-to-datetime.html
- Jonathan M Davis
Segfault when using SysTime
Hi,
(I'm not sure whether I should be posting these here...apologies if this is
inappropriate).
Test case: (test.d)
import std.datetime;
import std.stdio;
void main()
{
// SysTime is a struct that should be default initialised
SysTime unInitialisedTime;
// Will segfault on this next line...
writeln("Time is: ", unInitialisedTime );
writeln("ending now...");
}
Compiled with dmd 2.056: dmd -wi -oftest test.d.
Result:
Segmentation Fault.
I did attempt to delve into the intricacies of the std.datetime library, but
understanding the techniques used is currently beyond my skill level.
Obviously, something is not being initialised properly?
regards,
ted
--
Experience is simply the name we give our mistakes.
-- Oscar Wilde
Re: Spurious compiler warning ?
kenji hara wrote:
> 2011/11/3 knommad :
>> Hi,
>>
>> I'm a relative newcomer to D, and am enjoying the experience.
>>
>> I have a small testcase here that causes what seems to be a spurious
>> warning from the compiler (resulting code still works, however).
>>
>> Am I missing something??
>>
>> import std.stdio;
>> import std.traits;
>>
>> enum TestEnum
>> {
>> ONE = 1,
>> TWO = 2,
>> THREE = 3,
>> FOUR = 4
>> }
>>
>> void main()
>> {
>> // Generates warning - works as expected though
>> foreach( TestEnum member; EnumMembers!TestEnum )
>> {
>> if ( member == TestEnum.TWO )
>> continue;
>> writeln( "A: ", member );
>> }
>>
>> // No warning generated
>> foreach( TestEnum member; EnumMembers!TestEnum )
>> {
>> if ( member == TestEnum.TWO )
>> continue;
>> else
>> writeln( "B: ", member );
>> }
>>
>> // No warning generated
>> auto list = EnumMembers!TestEnum;
>> foreach( TestEnum member; list )
>> {
>> if ( member == TestEnum.TWO )
>> continue;
>> writeln( "C: ", member );
>> }
>>
>> }
>>
>> compiled with: dmd -wi -oftest test.d
>>
>> (dmd version 2.056)
>>
>> output is as expected:
>> A: ONE
>> A: THREE
>> A: FOUR
>> B: ONE
>> B: THREE
>> B: FOUR
>> C: ONE
>> C: THREE
>> C: FOUR
>>
>>
>> regards,
>> ted
>>
>> --
>> Money can't buy happiness. But it can buy marshmallows, which are kinda
>> the same thing.
>>
>>
>
> EnumMember returns tuple, it is compile-time sequence.
> And foreach with tuple unrolls its body. Then, Loop A is unrolled like
> follows.
>
> __foreachEntry0: {
> if ( TestEnum.ONE == TestEnum.TWO )
> goto __foreachEntry1;
> writeln( "A: ", TestEnum.ONE );
> }
> __foreachEntry1: {
> if ( TestEnum.TWO == TestEnum.TWO )
> goto __foreachEntry2;
> writeln( "A: ", TestEnum.TWO ); // LineX
> }
> __foreachEntry2: {
> if ( TestEnum.THREE == TestEnum.TWO )
> goto __foreachEntry3;
> writeln( "A: ", TestEnum.THREE );
> }
> __foreachEntry3: {
> if ( TestEnum.FOUR == TestEnum.TWO )
> goto __foreachEntry4;
> writeln( "A: ", TestEnum.FOUR );
> }
> __foreachEntry4:
> ;
>
> And, when member == TestEnum.TWO, the LineX is not reachable.
>
> With loop B, unrolling is similar, but dmd does not warn the
> unreachable else block.
> Because dmd treats it as that is stated by programmers as "may become
> unreachable branch".
> (This is reasonable assumption, sometimes the condition of if
> statement folded to constant.)
>
> With loop C, list is "tuple of local variable symbols", it is similar
> to follows.
>
> auto __list0 = TestEnum.ONE;
> auto __list1 = TestEnum.TWO;
> auto __list2 = TestEnum.THREE;
> auto __list3 = TestEnum.FOUR;
> alias TypeTuple!(list0, list1, list2, list3) list;
>
> list itself is compile time tuple, but its elements are evaluated at
> runtime. Loop C is unrolled like A and B, but the conditions are
> evaluated at runtime, then compiler does not warn the branches as
> unreachable.
>
> Kenji Hara
Hi,
Thanks for the detailed and informative answer.
I am puzzled, however, that there is an inconsistency. There were 3 examples
in the test case, which I would have expected to yield the same compiler
output - but it only generates a warning in the first example.
regards,
ted
--
If you're not failing every now and again, it's a sign you're not doing
anything very innovative.
--
Woody Allen
Re: Introspection/Reflection/etc on Linux
On Mon, Oct 24, 2011 at 12:47 AM, Jacob Carlborg wrote:
>
> You can foreach over ModuleInfo and access the classes using
> "localClasses". Have a look at the implementation of
> object.TypeInfo_Class.find in druntime.
>
>
> --
> /Jacob Carlborg
>
And here is the last piece of the puzzle:
void main(string[] args)
{
foreach(m; ModuleInfo)
{
//there are many modules, only choose what we're interested in
if (!startsWith(m.name, "dt"))
{
continue;
}
writeln(" module: ", m.name);
foreach(c; m.localClasses)
{
//need to exclude Base
if (!startsWith(c.name, m.name ~ ".X"))
{
continue;
}
writeln(" class:", c.name);
auto obj = Object.factory(c.name);
}
}
}
with the output:
$ rm -f dtest; dmd dtest.d variant.d -ofdtest; ./dtest
module: dtest
class:dtest.XBob
RunAllIn: dtest.XBob
== i=2 m=inBob1
in bob : inBob1()
== i=3 m=inBob2
in bob : inBob2()
class:dtest.XJane
RunAllIn: dtest.XJane
== i=1 m=inJane1
in jane : inJane1()
== i=2 m=inJane2
in jane : inJane2()
Many thanks Jacob!
John
Re: Native D MySQL Driver
On Nov 3, 2011, at 10:15 PM, Steve Teale wrote: > > I also have a question. MySQL potentially produces result sets of up to > 64 bit size - rows. The MySQL client theoretically copes with these by > storing a result set as a doubly linked list, and there's nothing to stop > me doing the same. But is it necessary? > > The whole point of a database seems to me to be to access the data you > need, rather than all the data in the Universe at the same time. Even if > I opt for result sets limited to 32 bit row numbers, if you pulled one > from the server with rows of only 20 bytes, you'd still be talking about > 80Gb of memory. Does any application do that sort of thing. I think they probably did this simply to avoid imposing an artificial limitation on the number of rows that may be returned, regardless of whether anyone would actually do so. Practically speaking… an app designed to move the entire contents of a table from one DB to another might do this, though it would be far from the most efficient means of doing so. I can't think of any realistic example of an app that would want more than 2^32 rows in a response.
