Mr. Fortin, thank you for your thorough response. I have just a few
comments.
On 5/17/11 9:07 PM, Michel Fortin wrote:
On 2011-05-17 20:00:55 -0400, Christopher the Magnificent
said:
Now I understand that another syntax has been nominated to do this job
which is the const(Object)ref syntax.
Christopher the Magnificent Wrote:
> Thanks for the background, Jesse Phillips. Do you have any thoughts on
> my proposed objconst/objimmutable syntax, as to whether you think it is
> readable, intuitive, and just whether you like it or don't like it?
I'm going to go withMichel's reply. Th
On 2011-05-14 21:16, Jonathan M Davis wrote:
> It recently came to my attention that an article on converting code from
> using std.date to using std.datetime would be of value, so I wrote one up.
> Since it's an article, and it's within the time period set by Walter for
> the article contest, I gu
So how do functions which take such a parameter look like?
void bar(ref Foo a, const(Foo) ref b) { }
or
void bar(ref Foo a, ref const(Foo) b) { }
On 2011-05-17 20:00:55 -0400, Christopher the Magnificent
said:
Now I understand that another syntax has been nominated to do this job
which is the const(Object)ref syntax.
I don't think there has been any official word on that. But many people
have shown support for it.
I dislike that sy
On 5/17/11 7:26 PM, Jesse Phillips wrote:
Christopher the Magnificent Wrote:
Greetings all. First time poster here.
By way of introduction, my name is Christopher. I've been fascinated
with D for a few years now. My main programming language has been
Python, but I have used and studied many
Christopher the Magnificent Wrote:
> Greetings all. First time poster here.
>
> By way of introduction, my name is Christopher. I've been fascinated
> with D for a few years now. My main programming language has been
> Python, but I have used and studied many programming languages to some
>
On 5/17/2011 5:52 PM, Robert Jacques wrote:
On Tue, 17 May 2011 20:44:24 -0400, Mehrdad
wrote:
On 5/17/2011 5:13 PM, Robert Jacques wrote:
T.tupleof has a problem though: It doesn't seem to let me actually
access the value; it just give me a tuple I can't do anything with.
Your example only
On Tue, 17 May 2011 20:52:02 -0400, Robert Jacques
wrote:
On Tue, 17 May 2011 20:44:24 -0400, Mehrdad
wrote:
On 5/17/2011 5:13 PM, Robert Jacques wrote:
On Tue, 17 May 2011 19:47:29 -0400, Mehrdad
wrote:
Is there any (hacky) way of accessing a private field from outside a
data typ
On Tue, 17 May 2011 20:44:24 -0400, Mehrdad wrote:
On 5/17/2011 5:13 PM, Robert Jacques wrote:
On Tue, 17 May 2011 19:47:29 -0400, Mehrdad
wrote:
Is there any (hacky) way of accessing a private field from outside a
data type? (The equivalent of reflection in managed languages.)
I'm try
> Thanks, but traits doesn't really let me read or write to the
> variable though. :(
Use getMember there.
foreach(member; __traits(allMembers, TYPE))
__traits(getMember, instance_of_type, member) = something;
tupleof is probably better for this though, since it only includes
actual data memb
On 5/17/2011 5:18 PM, Adam D. Ruppe wrote:
Check out the __traits(allMembers, TYPE) system:
http://dpldocs.info/traits
Thanks, but traits doesn't really let me read or write to the variable
though. :(
On 5/17/11 6:17 PM, %u wrote:
This is what Rebindable(T) is for:
http://www.digitalmars.com/d/2.0/phobos/std_typecons.html
Thanks for the reference, but to me, rebindable feels like a hack. My
opinion is that D deserves to have such an integral feature as mutable
references to const object
On 5/17/2011 5:13 PM, Robert Jacques wrote:
On Tue, 17 May 2011 19:47:29 -0400, Mehrdad
wrote:
Is there any (hacky) way of accessing a private field from outside a
data type? (The equivalent of reflection in managed languages.)
I'm trying to write a piece of marshaling code that needs acces
Check out the __traits(allMembers, TYPE) system:
http://dpldocs.info/traits
This is what Rebindable(T) is for:
http://www.digitalmars.com/d/2.0/phobos/std_typecons.html
On Tue, 17 May 2011 19:47:29 -0400, Mehrdad wrote:
Is there any (hacky) way of accessing a private field from outside a
data type? (The equivalent of reflection in managed languages.)
I'm trying to write a piece of marshaling code that needs access to a
data type's fields, but can't access
Greetings all. First time poster here.
By way of introduction, my name is Christopher. I've been fascinated
with D for a few years now. My main programming language has been
Python, but I have used and studied many programming languages to some
extent. I love to design things, like houses,
Is there any (hacky) way of accessing a private field from outside a
data type? (The equivalent of reflection in managed languages.)
I'm trying to write a piece of marshaling code that needs access to a
data type's fields, but can't access them because it's not allowed to. :(
On May 17, 2011, at 2:37 PM, Piotr Szturmaj wrote:
> Sean Kelly wrote:
>> On May 11, 2011, at 3:06 PM, Piotr Szturmaj wrote:
>>
>>> Andrei Alexandrescu wrote:
* can you implement save() to make this a forward range (e.g. by
creating a new fiber that has its own state)?
>>>
>>> It is no
> On 17.05.2011 20:06, Jonathan M Davis wrote:
> > StopWatch uses a mononotonic clock.
>
> Monotonic clock is not CPU-usage-bound - it is in sync with wall-time, so
> problem on busy systems remains.
A monotonic clock is as good as you're going to get for accurate stopwatch
functionality. The sy
Timon Gehr:
> Tuple literals would indeed be very nice.
I have asked for tuple unpacking syntax (and other things like some support
from the type system). Tuple literals are less needed.
> (having syntactic sugar for phobos functionality in the language
> seems like a very bad design to me,
I
On 17.05.2011 20:06, Jonathan M Davis wrote:
> StopWatch uses a mononotonic clock.
Monotonic clock is not CPU-usage-bound - it is in sync with wall-time, so
problem on busy systems remains.
/Alexander
Sean Kelly wrote:
On May 17, 2011, at 7:37 AM, Piotr Szturmaj wrote:
In regards to serializable fibers, I've found some interesting potential
usage - session handling in HTTP server. Fiber code could represent
session and could be saved to disk in the middle of execution, just
like sessions are
Sean Kelly wrote:
On May 11, 2011, at 3:06 PM, Piotr Szturmaj wrote:
Andrei Alexandrescu wrote:
* can you implement save() to make this a forward range (e.g. by
creating a new fiber that has its own state)?
It is not that simple I guess. Fiber class doesn't give any opportunity to save
>> cu
> Stewart Gordon:
>
> > I think D is going the right way on the whole by leaving regexps to a
> > library.
Though
> > this does limit such possibilities as optimised regexp switches.
>
> Leaving regexps to a library is an acceptable choice for D, or maybe even the
best choice. In D even associati
Am 17.05.2011 22:44, schrieb Stewart Gordon:
> On 12/05/2011 13:21, Matthew Ong wrote:
>> @dennis luehring
>
>> I do not think that this is syntactic sugar. Compare this 2 block of
>> code. Which
>> is easier to read?
>
>
> Features to improve the readability of code are the very definition of
>
On 12/05/2011 13:21, Matthew Ong wrote:
@dennis luehring
I do not think that this is syntactic sugar. Compare this 2 block of code. Which
is easier to read?
Features to improve the readability of code are the very definition of syntactic sugar.
Indeed, Prolog programmers rely on syntactic
Stewart Gordon:
> I think D is going the right way on the whole by leaving regexps to a
> library. Though
> this does limit such possibilities as optimised regexp switches.
Leaving regexps to a library is an acceptable choice for D, or maybe even the
best choice. In D even associative arrays
Den 17-05-2011 16:57, Robert Jacques skrev:
On Tue, 17 May 2011 07:24:16 -0400, Jonas Drewsen
wrote:
On 17/05/11 08.03, Robert Jacques wrote:
On Mon, 16 May 2011 17:07:57 -0400, jdrewsen
wrote:
Hi,
I've been working on a wrapper for the etc.c.curl module. It is now
pretty stable and I woul
Please see comments below.
Den 17-05-2011 16:42, Andrei Alexandrescu skrev:
Thanks for the response! A few more answers and comments within
(everything deleted counts as "sounds great").
On 5/17/11 3:50 AM, Jonas Drewsen wrote:
14. Isn't the max redirect configurable via a parameter?
Yes. It
On 5/17/11 4:02 AM, Jacob Carlborg wrote:
On 2011-05-16 02:05, Andrei Alexandrescu wrote:
Thanks for your work.
I think there's an important distinction to be made. There are two
"API"s being discussed. One is the client interface and the other is the
extensibility interface.
Jose looked into
On 13/05/2011 06:10, KennyTM~ wrote:
On May 13, 11 12:14, Ary Manzana wrote:
I didn't use regex a lot before I started using Ruby. The thing is, in
Ruby it's so easy to use regex that I just started using them a lot more
than before. Of course, ruby has built-in operators for matching regexs,
On 2011-05-17 12:34, Sean Kelly wrote:
> On May 17, 2011, at 11:06 AM, Jonathan M Davis wrote:
> > I very much support the idea of deprecating all of the functions in
> > druntime and phobos which take naked time values. And then if a function
> > that sleeps at nanosecond resolution is considered
On May 17, 2011, at 11:06 AM, Jonathan M Davis wrote:
>
> I very much support the idea of deprecating all of the functions in druntime
> and phobos which take naked time values. And then if a function that sleeps
> at
> nanosecond resolution is considered to be of real value (which I question),
On May 17, 2011, at 7:37 AM, Piotr Szturmaj wrote:
>
> In regards to serializable fibers, I've found some interesting potential
> usage - session handling in HTTP server. Fiber code could represent session
> and could be saved to disk in the middle of execution, just like sessions are
> saved i
On May 11, 2011, at 3:06 PM, Piotr Szturmaj wrote:
> Andrei Alexandrescu wrote:
>> * can you implement save() to make this a forward range (e.g. by
>> creating a new fiber that has its own state)?
>
> It is not that simple I guess. Fiber class doesn't give any opportunity to
> save current stack
On May 11, 2011, at 3:09 PM, Piotr Szturmaj wrote:
> %u wrote:
>> On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
>>> I forgot to ask. Any comments or suggestions?
>>
>> This is **beast**.
>>
>> Just one thing: Would it work correctly if I was using fibers in my
>> own code?
>
> I don't know. If
>
> If serialization will be clever enough, these fibers could even be shared
> across different servers! This is really a requirement in load balanced
> environments.
>
A very old research paper (I think it was for the amoeba project)
wrote a long time ago (I don't remember the wording) that is u
On 5/17/11 1:35 PM, Andrej Mitrovic wrote:
On 5/17/11, Andrei Alexandrescu wrote:
Yah, const(ubyte)[] is much more reasonable. We may as well add a
function representation() that returns it for any object.
Would this mean that e.g. you could save the state of an object to
disk via repr(), and
On May 17, 11 22:45, Andrei Alexandrescu wrote:
On 5/17/11 12:23 AM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:43:06 +0300, Andrei Alexandrescu
wrote:
3. Data on wire is ubyte[], not void[].
I was the one who suggested using void[]. If data on wire is ubyte[],
why is data on disk voi
On 5/17/11, Andrei Alexandrescu wrote:
> Yah, const(ubyte)[] is much more reasonable. We may as well add a
> function representation() that returns it for any object.
Would this mean that e.g. you could save the state of an object to
disk via repr(), and then retrieve the state at a later point?
On 5/17/11 1:00 PM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 20:43:11 +0300, Andrei Alexandrescu
wrote:
On 5/17/11 12:39 PM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 17:45:00 +0300, Andrei Alexandrescu
wrote:
On 5/17/11 12:23 AM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:
> On 17.05.2011 16:45, Steven Schveighoffer wrote:
> > The structures have used nanoseconds for over 10 years (I think
> > gettimeofday used it back in the 90s!), so the reason for using it was
> > likely for future compatibility (clearly nanosecond timing wasn't
> > possible back then). It looks l
> On Tue, 17 May 2011 09:42:27 -0400, Daniel Gibson
>
> wrote:
> > Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
> >> I agree that accepting a long as an alternative to Duration, it makes
> >> sense to use a more normal tick resolution. The chances of someone
> >> wanting to have their proce
On Tue, 17 May 2011 20:43:11 +0300, Andrei Alexandrescu
wrote:
On 5/17/11 12:39 PM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 17:45:00 +0300, Andrei Alexandrescu
wrote:
On 5/17/11 12:23 AM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:43:06 +0300, Andrei Alexandrescu
wrote:
3.
On 5/17/11 12:39 PM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 17:45:00 +0300, Andrei Alexandrescu
wrote:
On 5/17/11 12:23 AM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:43:06 +0300, Andrei Alexandrescu
wrote:
3. Data on wire is ubyte[], not void[].
I was the one who suggested
On Tue, 17 May 2011 17:45:00 +0300, Andrei Alexandrescu
wrote:
On 5/17/11 12:23 AM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:43:06 +0300, Andrei Alexandrescu
wrote:
3. Data on wire is ubyte[], not void[].
I was the one who suggested using void[]. If data on wire is ubyte[],
why
On 5/17/11 9:37 AM, Piotr Szturmaj wrote:
Piotr Szturmaj wrote:
Hi,
I've written some proof of concept code of generator pattern, example:
void genSquares(out int result, int from, int to)
{
foreach (x; from .. to + 1)
{
yield!result(x * x);
}
}
void main(string[] argv)
{
foreach (sqr; genera
On 17.05.2011 16:45, Steven Schveighoffer wrote:
> The structures have used nanoseconds for over 10 years (I think gettimeofday
> used it back in the 90s!), so the reason for using it was likely for future
> compatibility (clearly nanosecond timing wasn't possible back then). It
> looks like t
On Tue, 17 May 2011 07:24:16 -0400, Jonas Drewsen
wrote:
On 17/05/11 08.03, Robert Jacques wrote:
On Mon, 16 May 2011 17:07:57 -0400, jdrewsen
wrote:
Hi,
I've been working on a wrapper for the etc.c.curl module. It is now
pretty stable and I would very much like some feedback on the API.
On Tue, 17 May 2011 09:55:49 -0400, Alexander wrote:
On 17.05.2011 15:25, Steven Schveighoffer wrote:
Plus, we have good precedence, both Microsoft and Tango use that tick
duration. It's a natural conclusion.
Linux/Posix are using ns (clock_gettime(), nanosleep() etc - timespec)
- I g
On Tue, 17 May 2011 09:42:27 -0400, Daniel Gibson
wrote:
Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
I agree that accepting a long as an alternative to Duration, it makes
sense to use a more normal tick resolution. The chances of someone
wanting to have their process sleep for more
Thanks for the response! A few more answers and comments within
(everything deleted counts as "sounds great").
On 5/17/11 3:50 AM, Jonas Drewsen wrote:
3. Data on wire is ubyte[], not void[].
Data received is ubyte[] and a convenience method for conversion to
string is provided.
Data send is
On 5/17/11 12:23 AM, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:43:06 +0300, Andrei Alexandrescu
wrote:
3. Data on wire is ubyte[], not void[].
I was the one who suggested using void[]. If data on wire is ubyte[],
why is data on disk void[] (according to std.file.read/write)?
Bug in
Piotr Szturmaj wrote:
Hi,
I've written some proof of concept code of generator pattern, example:
void genSquares(out int result, int from, int to)
{
foreach (x; from .. to + 1)
{
yield!result(x * x);
}
}
void main(string[] argv)
{
foreach (sqr; generator(&genSquares, 10, 20))
writeln(sqr);
}
On 17.05.2011 15:25, Steven Schveighoffer wrote:
> if you use hnsecs, then you get a range of SysTime of -30k to 30k years.
> That might seem overkill, but consider that even going to dnsecs (10
> nanoseconds) reduces your range to -3k to +3k years. The problem is that
> nobody is likely to c
Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
>
> I agree that accepting a long as an alternative to Duration, it makes
> sense to use a more normal tick resolution. The chances of someone
> wanting to have their process sleep for more than 300 years (e.g. for
> nanosecond resolution) is pre
On 17.05.2011 15:44, Alexander wrote:
On 17.05.2011 12:34, Jonathan M Davis wrote:
Also, the system clock definitely does not reach hnsecs on any system that I've
seen.
Duration (unlike TickDuration) is not tied to system clock only, AFAIK (at
least, this is not mentioned in the documenta
On Tue, 17 May 2011 06:15:54 -0400, Alexander wrote:
...why it is in hnsec? I know that this resolution is used in Win32 API
(file time), but since TickDuration may be 1 ns resolution, wouldn't it
be better to make Duration to be stored with maximum (defined so far)
resolution?
if you us
On Tue, 17 May 2011 00:04:07 -0400, Don wrote:
Nick Sabalausky wrote:
"Steven Schveighoffer" wrote in message
news:op.vvk48tn9eav7ka@localhost.localdomain...
(int/short/byte can sometimes implicitly cast to dchar/wchar/char)
What do you think?
Ick! Kill it!
It's not easy. Simply disa
On 17.05.2011 12:34, Jonathan M Davis wrote:
> Also, the system clock definitely does not reach hnsecs on any system that
> I've seen.
Duration (unlike TickDuration) is not tied to system clock only, AFAIK (at
least, this is not mentioned in the documentation).
Using rdtsc it is possible t
On 17/05/11 08.03, Robert Jacques wrote:
On Mon, 16 May 2011 17:07:57 -0400, jdrewsen wrote:
Hi,
I've been working on a wrapper for the etc.c.curl module. It is now
pretty stable and I would very much like some feedback on the API.
http://freeze.steamwinter.com/D/web/phobos/etc_curl.html
BT
On 2011-05-17 03:15, Alexander wrote:
> ...why it is in hnsec? I know that this resolution is used in Win32 API
> (file time), but since TickDuration may be 1 ns resolution, wouldn't it be
> better to make Duration to be stored with maximum (defined so far)
> resolution?
>
> Especially because Dur
...why it is in hnsec? I know that this resolution is used in Win32 API (file
time), but since TickDuration may be 1 ns resolution, wouldn't it be better to
make Duration to be stored with maximum (defined so far) resolution?
Especially because Duration may not hold long intervals (> months) - s
On 2011-05-16 02:05, Andrei Alexandrescu wrote:
Thanks for your work.
I think there's an important distinction to be made. There are two
"API"s being discussed. One is the client interface and the other is the
extensibility interface.
Jose looked into both: he provided a client interface that h
On 17/05/11 07.23, Vladimir Panteleev wrote:
On Tue, 17 May 2011 07:43:06 +0300, Andrei Alexandrescu
wrote:
3. Data on wire is ubyte[], not void[].
I was the one who suggested using void[]. If data on wire is ubyte[],
why is data on disk void[] (according to std.file.read/write)?
I believ
On 17/05/11 06.43, Andrei Alexandrescu wrote:
On 05/16/2011 04:07 PM, jdrewsen wrote:
Hi,
I've been working on a wrapper for the etc.c.curl module. It is now
pretty stable and I would very much like some feedback on the API.
http://freeze.steamwinter.com/D/web/phobos/etc_curl.html
BTW I use t
On 2011-05-16 23:07, jdrewsen wrote:
Hi,
I've been working on a wrapper for the etc.c.curl module. It is now
pretty stable and I would very much like some feedback on the API.
http://freeze.steamwinter.com/D/web/phobos/etc_curl.html
BTW I use template mixins which doesn't seem to get included
"Walter Bright" wrote in message
news:iqsu2b$1aqs$1...@digitalmars.com...
> On 5/16/2011 9:09 PM, Jonathan M Davis wrote:
>> On 2011-05-16 21:04, Don wrote:
>>> It's not easy. Simply disallowing it would make code like this illegal:
>>>
>>> char c = '0' + n;
>>
>> Well, forcing the n to be cast t
On 2011-05-16 01:27, Jonathan M Davis wrote:
On 2011-05-15 16:01, Andrei Alexandrescu wrote:
On 05/15/2011 10:26 AM, Jacob Carlborg wrote:
On 2011-05-15 00:33, Andrei Alexandrescu wrote:
On 05/14/2011 05:17 PM, Jonathan M Davis wrote:
On 2011-05-14 14:56, Michel Fortin wrote:
On 2011-05-14 1
On 2011-05-16 01:04, Andrei Alexandrescu wrote:
On 05/15/2011 10:22 AM, Jacob Carlborg wrote:
On 2011-05-14 22:37, Andrei Alexandrescu wrote:
I want to nail usability before extension. Extensibility can be provided
via an indirection inside FileLogger (which should indeed receive a more
appropr
On 17/05/11 02.43, dsimcha wrote:
== Quote from jdrewsen (jdrew...@nospam.com)'s article
Hi,
I've been working on a wrapper for the etc.c.curl module. It is now
pretty stable and I would very much like some feedback on the API.
http://freeze.steamwinter.com/D/web/phobos/etc_curl.html
BTW I
73 matches
Mail list logo
