ur IRC discussion was more about simplifying the Phobos
interface through breaking changes than actually just dropping
and rewriting. Most the "phobos 2" would just be today's
phobos with mistakes changed, autodecoding deprecated then
removed, eager functions same deal (the discussi
On Saturday, 3 June 2017 at 06:37:27 UTC, H. S. Teoh wrote:
And by putting the modified modules in a new temporary
namespace, we can ease the transition enough that perhaps we
might actually see this happen, one day. (Haha, so I hope.)
Javax ?
the Phobos interface
> through breaking changes than actually just dropping and rewriting.
> Most the "phobos 2" would just be today's phobos with mistakes
> changed, autodecoding deprecated then removed, eager functions same
> deal (the discussion that started it was sp
gh), because then if you do
completely rewrite something, you can verify that it's correct.
As for "Phobos 2" specifically though, I have very mixed
feelings about such an idea. Being able to rearrange things how
we'd like and fix some of the mistakes that we've been stuck
with would b
On Friday, 2 June 2017 at 20:37:05 UTC, H. S. Teoh wrote:
Especially the bit about throwing away years of accumulated
programming work.
Our IRC discussion was more about simplifying the Phobos
interface through breaking changes than actually just dropping
and rewriting. Most the "pho
ing standard libraries. If you
> >> seriously propose this path, I hope Andrei and Walter will publicly
> >> and vehemently oppose it. Otherwise that ghost from the past becomes a
> >> PR disaster for D.
> >
> > [...]
> >
> > I think this is overreacting. &
does really fix problems -
especially when the original has serious design problems that can't be fixed
without redoing it. However, thinking about what he's saying there, it
starts looking like the most valuable part of your code base is your tests
(assuming that they're thorough), because t
On Fri, Jun 02, 2017 at 02:43:32PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
> A clean slate is alluring, and there are several things that can be done
> differently in Phobos, as there are in any project that's been around for a
> while. It may, however, be difficult to find
On Friday, 2 June 2017 at 18:43:32 UTC, Andrei Alexandrescu wrote:
A clean slate is alluring, and there are several things that
can be done differently in Phobos, as there are in any project
that's been around for a while. It may, however, be difficult
to find enough people able and willing
that ghost from the past becomes a
PR disaster for D.
[...]
I think this is overreacting. "Phobos 2" is not supposed to be a
*competing* library, but, as I see it, more like an alpha version of the
next "major iteration" of Phobos. The "next major version" wit
saster for D.
[...]
I think this is overreacting. "Phobos 2" is not supposed to be a
*competing* library, but, as I see it, more like an alpha version of the
next "major iteration" of Phobos. The "next major version" with a brand
new paradigm, if you will, as opposed to
On Friday, 2 June 2017 at 09:14:14 UTC, qznc wrote:
Frankly, I do not see the need for Phobos2. If you want to
build alternative packages, just go ahead and publish them via
dub like Mir, for example. You can even make a meta package, if
you find yourself using the same group of packages all
and creating a
Phobos 2? It wouldn't replace the current version. You could
import either in one program. It also wouldn't be a radical
redesign. Most of Phobos could be used as is. What it would do
is allow fixing some hard or impossible problems without losing
backward compatibility.
We could do away
that it is range based). What about
taking all the lessons learned from Phobos and creating a
Phobos 2? It wouldn't replace the current version. You could
import either in one program. It also wouldn't be a radical
redesign. Most of Phobos could be used as is. What it would do
is allow fixing some hard
and creating a
Phobos 2? It wouldn't replace the current version. You could
import either in one program. It also wouldn't be a radical
redesign. Most of Phobos could be used as is. What it would do
is allow fixing some hard or impossible problems without losing
backward compatibility.
Mir libraries
and creating a
Phobos 2? It wouldn't replace the current version. You could
import either in one program. It also wouldn't be a radical
redesign. Most of Phobos could be used as is. What it would do
is allow fixing some hard or impossible problems without losing
backward compatibility.
[...]
Maybe we
> learned from Phobos and creating a Phobos 2? It wouldn't replace the
> current version. You could import either in one program. It also
> wouldn't be a radical redesign. Most of Phobos could be used as is.
> What it would do is allow fixing some hard or impossible problems
>
On 2017-06-01 20:40, Brad Anderson wrote:
I am curious to hear what changes you'd all like to see made to Phobos that
can't happen because
of backward compatibility.
Perhaps completely asynchronous IO throughout.
--
/Jacob Carlborg
A (surely controversial) idea popped into my head while talking
in #d on Freenode. The C++ guys are making an STL2 (the highlight
of it being that it is range based). What about taking all the
lessons learned from Phobos and creating a Phobos 2? It wouldn't
replace the current version. You
On 2009-04-13 20:33:53 +0200, Frits van Bommel
fvbom...@remwovexcapss.nl said:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
Or you can pin anything that's referenced
Fawzi Mohamed, el 15 de abril a las 14:57 me escribiste:
Well, if it turns out to be a win, I'm sure we could put it into LDC.
DMD would be up to Walter.
and tango will also for sure welcome a new gc implementation.
Well, right now I'm working on a minimal, naive, fully documented GC
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
On Mon, 13 Apr 2009 14:54:57 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
[snip]
An alternative to this is to encode the information in ClassInfo and
use
It's already
Robert Jacques wrote:
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
it instead. (You'd have to create a fake ClassInfo for structs and
arrays.) Then the GC only has to track the start of each object (i.e.
the beginning of a block
On Tue, 14 Apr 2009 11:34:05 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
On Tue, 14 Apr 2009 09:27:09 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
Leandro Lucarella wrote:
Christopher Wright, el 12 de abril a las 17:54 me escribiste:
Absolutely. When writing parallel code to do large scale data mining in D, the
lack of precision and multithreaded allocation are real killers. My interests
are, in order of importance:
1. Being able to
Sean Kelly wrote:
Leandro Lucarella wrote:
But right now gc_malloc() doesn't take any TypeInfo argument. I can't see
where I can get the TypeInfo in the first place =/
The call would have to be modified. Right now the best you can do is
pass BlkAttr.NO_SCAN. And storing a pointer per block
Robert Jacques, el 11 de abril a las 01:05 me escribiste:
On Fri, 10 Apr 2009 23:04:16 -0400, Leandro Lucarella llu...@gmail.com
wrote:
I hope I can come up with something useful with my thesis (improving D's
GC) and I can contribute that. Right now all my energies are focused on
that, and
dsimcha, el 11 de abril a las 05:21 me escribiste:
== Quote from Leandro Lucarella (llu...@gmail.com)'s article
Andrei Alexandrescu, el 10 de abril a las 16:49 me escribiste:
And Braddr just made a documentation fix, and Walter only commits
portability stuff and an occasional bug fix now
On Sun, 12 Apr 2009 21:13:09 +0400, Leandro Lucarella llu...@gmail.com wrote:
Robert Jacques, el 11 de abril a las 01:05 me escribiste:
On Fri, 10 Apr 2009 23:04:16 -0400, Leandro Lucarella
llu...@gmail.com wrote:
I hope I can come up with something useful with my thesis (improving
D's
GC)
Denis Koroskin, el 12 de abril a las 21:26 me escribiste:
I think I'll target D1 for now. The reasons are:
* Stability
* Free compilers availability (you know what kind of free I'm talking
about =)
* Programs availability (I'm trying to gather programs to make a benchmark
suite, without
Leandro Lucarella wrote:
dsimcha, el 11 de abril a las 05:21 me escribiste:
== Quote from Leandro Lucarella (llu...@gmail.com)'s article
Andrei Alexandrescu, el 10 de abril a las 16:49 me escribiste:
And Braddr just made a documentation fix, and Walter only commits
portability stuff and an
Christopher Wright, el 12 de abril a las 17:54 me escribiste:
Absolutely. When writing parallel code to do large scale data mining in D,
the
lack of precision and multithreaded allocation are real killers. My
interests
are, in order of importance:
1. Being able to allocate at least
Leandro Lucarella llu...@gmail.com kirjoitti viestissä
news:20090411030416.ga22...@homero.springfield.home...
BTW, is there any real interest in adding some more power to the GC
implementator to allow some kind of moving or generational collector?
What I mostly want/need from the GC would be
Andrei Alexandrescu schrieb:
Zz wrote:
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
I wanted to add logging support for a while now but am undecided about
the API to use. Log4J is quite popular but quite complicated. There are
a number of simpler APIs out there
Rioshin an'Harthen wrote:
Leandro Lucarella llu...@gmail.com kirjoitti viestissä
news:20090411030416.ga22...@homero.springfield.home...
BTW, is there any real interest in adding some more power to the GC
implementator to allow some kind of moving or generational collector?
What I mostly
== Quote from grauzone (n...@example.net)'s article
Rioshin an'Harthen wrote:
Leandro Lucarella llu...@gmail.com kirjoitti viestissä
news:20090411030416.ga22...@homero.springfield.home...
BTW, is there any real interest in adding some more power to the GC
implementator to allow some kind
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
Zz wrote:
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
Why ask. Phobos is a one man show. In other word, Phobos is an ego-lib.
In case that you want something special, ask the tango folks. ( beside,
logging is avail. there for quite a while)
Björn
Zz wrote:
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
I wanted to add logging support for a while now but am undecided about
the API to use. Log4J is quite popular but quite complicated. There are
a number of simpler APIs out there but I couldn't figure out which is
BLS wrote:
Zz wrote:
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
Why ask. Phobos is a one man show. In other word, Phobos is an ego-lib.
That's a rather random thing to say, particularly in wake of the recent
concerted efforts to improve Phobos and to port it to
On Fri, Apr 10, 2009 at 09:20:46AM -0700, Andrei Alexandrescu wrote:
If anyone has ideas and/or code to contribute, that would be great.
I never understood why they should be complicated. Couldn't you just do
something like (pseudocodeish):
==
enum LogLevel { Verbose, Warning, Error }
BLS wrote:
Zz wrote:
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
Why ask. Phobos is a one man show. In other word, Phobos is an ego-lib.
In case that you want something special, ask the tango folks. ( beside,
logging is avail. there for quite a while)
Björn
It's
Christopher Wright, el 10 de abril a las 16:18 me escribiste:
BLS wrote:
Zz wrote:
Hi,
Are there any plans for a logging library in Std Phobos 2.0?
Zz
Why ask. Phobos is a one man show. In other word, Phobos is an ego-lib.
In case that you want something special, ask the tango folks. (
Andrei Alexandrescu, el 10 de abril a las 16:49 me escribiste:
And Braddr just made a documentation fix, and Walter only commits
portability stuff and an occasional bug fix now and then, so...
Yes, it really looks like a five-person show =)
I think most work in Phobos now it's done by Andrei,
On Fri, 10 Apr 2009 23:04:16 -0400, Leandro Lucarella llu...@gmail.com
wrote:
I hope I can come up with something useful with my thesis (improving D's
GC) and I can contribute that. Right now all my energies are focused on
that, and I'm very close to the point to finally start playing with
can keep up with what the heck is going on. While
you
appear to have done a great job on the new Phobos and things appear to be
settling
down now, in the interim trying to figure out what was and wasn't going to be
completely turned upside down by ranges and Phobos 2 made contributing small
46 matches
Mail list logo
