On Mon, 28 Nov 2011 15:32:23 +0200, Steven Schveighoffer
wrote:
Yes, but let's not call this a "range", since it does not work in
functions that use ranges or with foreach (this is Walter's goal).
How bout strange? (Yes, i am bored)
On Mon, 28 Nov 2011 08:18:38 -0500, so wrote:
On Mon, 28 Nov 2011 14:54:07 +0200, Steven Schveighoffer
wrote:
On Sat, 26 Nov 2011 16:39:38 -0500, Walter Bright
wrote:
On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
Ranges are not good for reading N bytes from a file
descriptor.
On Mon, 28 Nov 2011 14:54:07 +0200, Steven Schveighoffer
wrote:
On Sat, 26 Nov 2011 16:39:38 -0500, Walter Bright
wrote:
On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
Ranges are not good for reading N bytes from a file
descriptor.
Why not? Isn't that exactly what a range is suppo
On Sat, 26 Nov 2011 16:39:38 -0500, Walter Bright
wrote:
On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
Ranges are not good for reading N bytes from a file
descriptor.
Why not? Isn't that exactly what a range is supposed to be good for?
A range has a specific interface:
T front()
vo
Manu wrote:
On 26 November 2011 23:39, Walter Bright mailto:newshou...@digitalmars.com>> wrote:
On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
Ranges are not good for reading N bytes from a file
descriptor.
Why not? Isn't that exactly what a range is supposed to be
On 26 November 2011 23:39, Walter Bright wrote:
> On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
>
>> Ranges are not good for reading N bytes from a file
>> descriptor.
>>
>
> Why not? Isn't that exactly what a range is supposed to be good for?
>
It sounds like a bad idea to me... I can imag
On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
Ranges are not good for reading N bytes from a file
descriptor.
Why not? Isn't that exactly what a range is supposed to be good for?
On Wed, 23 Nov 2011 21:26:45 -0500, Walter Bright
wrote:
On 11/19/2011 7:02 PM, dsimcha wrote:
* Streams. (Another item where the bottleneck is mostly at the design
level and
people not really knowing what they want.)
I'm not sure what the purpose of streams would be, now that we have
Le 23/11/2011 21:35, Jude Young a écrit :
> er working on a specific binding to a C
> library, just drop me an email or something.
> The small ones like ZeroMQ can be done in a few hours or so. A little
> longer to test properly.
Awesome. :)
I hope this one will get the publicity it deserves.
On Wednesday, November 23, 2011 22:21:47 dsimcha wrote:
> On 11/23/2011 9:26 PM, Walter Bright wrote:
> > On 11/19/2011 7:02 PM, dsimcha wrote:
> >> * Streams. (Another item where the bottleneck is mostly at the design
> >> level and
> >> people not really knowing what they want.)
> >
> > I'm not
On 11/23/2011 9:26 PM, Walter Bright wrote:
On 11/19/2011 7:02 PM, dsimcha wrote:
* Streams. (Another item where the bottleneck is mostly at the design
level and
people not really knowing what they want.)
I'm not sure what the purpose of streams would be, now that we have ranges.
Right. As
On 11/19/2011 7:02 PM, dsimcha wrote:
* Compression/archiving. (Opening standard compressed/archived file formats
needs to just work. This includes at least zip, gzip, tar and bzip2. Of course,
zip already is available and gzip is supported by the zlib module but with a
crufty C API. At least gzi
On 11/19/2011 7:02 PM, dsimcha wrote:
* Streams. (Another item where the bottleneck is mostly at the design level and
people not really knowing what they want.)
I'm not sure what the purpose of streams would be, now that we have ranges.
On 23 November 2011 21:35, Martin Nowak wrote:
> On Wed, 23 Nov 2011 18:20:35 +0100, Manu wrote:
>
> Oh wow, awesome! :)
>> I'm always surprised by the state of the D libraries.. There's already
>> lots
>> of awesome obscure things are in there, but also completely obvious major
>> features bla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/23/2011 11:20 AM, Manu wrote:
> Oh wow, awesome! :) I'm always surprised by the state of the D
> libraries.. There's already lots of awesome obscure things are in
> there, but also completely obvious major features blatantly missing
> :)
>
> So
On Wed, 23 Nov 2011 18:20:35 +0100, Manu wrote:
Oh wow, awesome! :)
I'm always surprised by the state of the D libraries.. There's already
lots
of awesome obscure things are in there, but also completely obvious major
features blatantly missing :)
There are some real gems, e.g. findRoot.
Oh wow, awesome! :)
I'm always surprised by the state of the D libraries.. There's already lots
of awesome obscure things are in there, but also completely obvious major
features blatantly missing :)
So how about a DCT? Image/video processing... Perhaps a simple adaptation
of FFT?
And it's not cl
Yeah, this is problematic. In voting against my allocator proposal,
Andrei mentioned that he wanted the allocators to be well-tested in the
container API first. This means either we have a circular dependency or
allocators and containers need to be co-developed. Co-developing them
is pro
On Wed, 23 Nov 2011 14:15:39 +0100, Somedude
wrote:
Le 20/11/2011 15:28, Adam D. Ruppe a écrit :
Johannes Pfau Wrote:
High performance IO: A reactor / proactor framework
Oh that reminds me, I'd like a nice thing for networking too, where you
can do something like register callback functio
*Crypto *- +1 as mentioned above, blocked on streams...
*Higher level maths/signal processing *- The linear algebra library
mentioned in a previous post might be very useful, but also standard
algorithms like fourier transforms. Library implementations of these
would
http://www.d-programming-l
On 20 November 2011 05:02, dsimcha wrote:
> Now that we've got a lot of contributors to Phobos and many projects in
> the works, I decided to start a thread to help us make a rough plan for
> Phobos's short-to-medium term development. There are three goals here:
>
> 1. Determine what's next in
Le 20/11/2011 15:28, Adam D. Ruppe a écrit :
> Johannes Pfau Wrote:
>> High performance IO: A reactor / proactor framework
>
> Oh that reminds me, I'd like a nice thing for networking too, where you
> can do something like register callback functions for events and it
> handles the rest for you.
On 2011-11-21 16:30, Steven Schveighoffer wrote:
On Sun, 20 Nov 2011 08:53:27 -0500, Jacob Carlborg wrote:
On 2011-11-20 04:02, dsimcha wrote:
* Better support for creating processes/new std.process. (Lars
Kyllingstad wrote a replacement candidate for Posix and Steve
Schveighoffer ported it t
On Sat, 19 Nov 2011 22:02:33 -0500, dsimcha wrote:
>
> * std.database. (Apparently Steve Teale is working on this. This is a
> large, complicated project because we're trying to define a common API
> for a variety of RDBMSs. Again, it's more a design problem than an
> implementation problem.)
On Sun, 20 Nov 2011 08:53:27 -0500, Jacob Carlborg wrote:
On 2011-11-20 04:02, dsimcha wrote:
* Better support for creating processes/new std.process. (Lars
Kyllingstad wrote a replacement candidate for Posix and Steve
Schveighoffer ported it to Windows, but issues with the DMC runtime
prevent
On Sun, 20 Nov 2011 09:07:44 -0500, Mike Wey wrote:
On 11/20/2011 04:02 AM, dsimcha wrote:
* Streams. (Another item where the bottleneck is mostly at the design
level and people not really knowing what they want.)
Steven Schveighoffer's new-stdio included a nice stream interface.
I don't kno
On 20-11-2011 22:19, Jesse Phillips wrote:
On Sun, 20 Nov 2011 15:12:27 -0500, dsimcha wrote:
On 11/20/2011 12:30 PM, Jonas Drewsen wrote:
If noone else wants to volunteer, I will again. Is there something I'm
missing? I find that being review manage takes very little effort: Post
an initial
On Sun, 20 Nov 2011 15:12:27 -0500, dsimcha wrote:
> On 11/20/2011 12:30 PM, Jonas Drewsen wrote:
> If noone else wants to volunteer, I will again. Is there something I'm
> missing? I find that being review manage takes very little effort: Post
> an initial review announcement, post a reminder,
On 11/20/2011 12:30 PM, Jonas Drewsen wrote:
* Some higher level networking support, such as HTTP, FTP, etc. (Jonas
Drewsen's CURL wrapper handles a lot of this and may be ready for a
second round of review.)
As I've mentioned in another thread it is ready for a second round of
review. We just
On 11/20/2011 12:30 PM, Jonas Drewsen wrote:
* Containers. (AFAIK noone is working on this. It's tough to get started
because, despite lots of discussion at various times on this forum,
noone seems to really know what they want. Since the containers in
question are well-known, it's much more a de
On 2011-11-20 18:14, Adam D. Ruppe wrote:
Jacob Carlborg Wrote:
If you know a module will break you can keep your own copy and decide if
you want to migrate to the new module or keep the old one.
Encouraging countless forks probably isn't a good idea toward building
a coordinated community.
>
> If you know a module will break you can keep your own copy and decide if
> you want to migrate to the new module or keep the old one.
>
Instead of introducing big and breaking changes to a module, we cood keep
std.json and introduce std.json2.
Den 20-11-2011 04:02, dsimcha skrev:
Now that we've got a lot of contributors to Phobos and many projects in
the works, I decided to start a thread to help us make a rough plan for
Phobos's short-to-medium term development. There are three goals here:
1. Determine what's next in the review queue
Jimmy Cao Wrote:
> The biggest thing impairing std.json imo is this bug:
> http://d.puremagic.com/issues/show_bug.cgi?id=2962
Note you can work around that with this.
Create a file called icehack.d:
module icehack;
import std.json;
static if(__traits(compiles, parseJSON("hello"))) {}
then on yo
2011/11/20 Johannes Pfau
>
>
> A replacement for std.json
>
The biggest thing impairing std.json imo is this bug:
http://d.puremagic.com/issues/show_bug.cgi?id=2962
Jacob Carlborg Wrote:
> If you know a module will break you can keep your own copy and decide if
> you want to migrate to the new module or keep the old one.
Encouraging countless forks probably isn't a good idea toward building
a coordinated community.
On 2011-11-20 15:28, Adam D. Ruppe wrote:
Johannes Pfau Wrote:
High performance IO: A reactor / proactor framework
Oh that reminds me, I'd like a nice thing for networking too, where you
can do something like register callback functions for events and it
handles the rest for you.
A replaceme
dsimcha wrote:
* Encryption and hashing. (This is more an implementation problem than a
design problem and AFAIK noone is working on it.)
There were some attempts to do so. See "Early std.crypto" thread.
Johannes Pfau Wrote:
> High performance IO: A reactor / proactor framework
Oh that reminds me, I'd like a nice thing for networking too, where you
can do something like register callback functions for events and it
handles the rest for you.
> A replacement for std.json
Blah, that will break a lo
dsimcha Wrote:
> * Compression/archiving. (Opening standard compressed/archived file
> formats needs to just work. This includes at least zip, gzip, tar and
> bzip2. Of course, zip already is available and gzip is supported by the
> zlib module but with a crufty C API.
I did a patch a coupl
On 11/20/2011 04:02 AM, dsimcha wrote:
* Streams. (Another item where the bottleneck is mostly at the design
level and people not really knowing what they want.)
Steven Schveighoffer's new-stdio included a nice stream interface.
I don't know what the current state of the module is.
--
Mike Wey
On 2011-11-20 04:02, dsimcha wrote:
Now that we've got a lot of contributors to Phobos and many projects in
the works, I decided to start a thread to help us make a rough plan for
Phobos's short-to-medium term development. There are three goals here:
1. Determine what's next in the review queue
On 20-11-2011 11:48, Johannes Pfau wrote:
dsimcha wrote:
Now that we've got a lot of contributors to Phobos and many projects
in the works, I decided to start a thread to help us make a rough plan
for Phobos's short-to-medium term development. There are three goals
here:
1. Determine what's n
dsimcha wrote:
>Now that we've got a lot of contributors to Phobos and many projects
>in the works, I decided to start a thread to help us make a rough plan
>for Phobos's short-to-medium term development. There are three goals
>here:
>
>1. Determine what's next in the review queue after std.csv (
On Sat, 19 Nov 2011 22:02:33 -0500
dsimcha wrote:
> 2. Come up with a wish list of high-priority modules that Phobos is
> missing that would make D a substantially more attractive language
> than it is now.
That's probably not for the Phobos, but having clear roadmap for the
GUI bindings proj
dsimcha:
> I decided to start a thread to help us make a rough plan for
> Phobos's short-to-medium term development.
Not too much time ago there was a Phobos wish list thread. I suggest you to
take a look at it (it contains my answer too, so I think there is no need to
repeat it here).
> 2.
Now that we've got a lot of contributors to Phobos and many projects in
the works, I decided to start a thread to help us make a rough plan for
Phobos's short-to-medium term development. There are three goals here:
1. Determine what's next in the review queue after std.csv (voting on
std.csv
47 matches
Mail list logo
