On 2015-02-23 21:30, Walter Bright wrote:
Count me among those.
In Java, write barriers make sense because Java uses the GC for
everything. Pretty much every indirection is a GC reference.
This is not at all true with D code. But since the compiler can't know
that, it has to insert write barri
On 2/23/2015 9:59 PM, Jonathan M Davis via Digitalmars-d wrote:
And delete is supposed to have been deprecated ages ago, but yeah, it
_definitely_ shouldn't be considered @safe.
Managing memory always is going to be unsafe. The idea is to encapsulate that,
which RCArray shows how to do.
On Monday, February 23, 2015 15:28:21 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 2/23/15 2:15 PM, Walter Bright wrote:
> > This is pretty straightforward.
> [snip]
>
> The code builds if you slap a "@safe:" at the top. There is one bug in
> the compiler: "delete" must not be allowed in @saf
ahem. seems that you are right, and i outsmarted myself yet
again. seems
that my head is too small to keep three different task unmessed
(forum
discussion, plus two of my projects).
sorry.
If it's any consolation, I did accidentally use a C++ constructor
in my first example..
I better sleep
On Tue, 24 Feb 2015 03:22:10 +, bitwise wrote:
> I think you're getting confused between "stackless" and "stackful"
> resumable functions.
ahem. seems that you are right, and i outsmarted myself yet again. seems
that my head is too small to keep three different task unmessed (forum
discussi
On Tuesday, 24 February 2015 at 00:48:34 UTC, ketmar wrote:
On Mon, 23 Feb 2015 23:10:28 +, bitwise wrote:
you still thinking in terms of generators. Generator is a
high-level construct, resumable routine is a low-level
construct. latter is used to build the former.
I think you're getti
On Tuesday, 24 February 2015 at 01:43:11 UTC, Andrei Alexandrescu
wrote:
This is a free world. Walter and I are working on a DIP. Please
work on yours. I can't promise we'll choose to your liking, but
this is the one way you can make your point heard and
understood. What doesn't work is trash t
On Tuesday, 24 February 2015 at 02:06:07 UTC, Walter Bright wrote:
On 2/23/2015 5:41 PM, weaselcat wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright
wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in
DIP25 at
On 2/23/2015 5:41 PM, weaselcat wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in DIP25 at all.
The 'this' is passed by reference. So the 'return' is really
On 2/23/15 5:43 PM, Andrei Alexandrescu wrote:
But please don't consider me an idiot because I don't like what you
propose.
Hmmm... actually I take that back :o). You are totally free to consider
me such (or at least of intellect inferior to yours etc). What I mean is
please don't consider me
On 2/23/15 5:23 PM, deadalnix wrote:
So far, what I feel from you and Walter is the will to not go into that
direction and instead created a myriad of hacks for various special
cases. I do think this is wrong headed and generally not the way
forward. Languages should provide the most generic and
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in DIP25
at all.
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu
wrote:
That's not feasible. Code that assumes the class object will
live forever can simply do things that are not allowed to code
that must assume the object will go away at some determined
point. Consider this which I just poste
On 2/23/2015 4:13 PM, bearophile wrote:
5. bounds checking
When you go past bounds of a built-in array you get an error located in the user
code, while if you put a pre-condition in your Array struct to detect the same
errors, you get a run-time error message located in that pre-condition inste
On 2/23/2015 5:01 PM, Max Klyga wrote:
I thought that delete is deprecated, yet here Walter himself promotes a solution
that uses it.
Can we *PLEASE* finally deprecate things that are supposed to be deprecated and
remove things that are supposed to be removed?
That isn't the point. I could have
I thought that delete is deprecated, yet here Walter himself promotes a
solution that uses it.
Can we *PLEASE* finally deprecate things that are supposed to be
deprecated and remove things that are supposed to be removed?
On 2015-02-23 22:15:46 +, Walter Bright said:
This is pretty straig
On Monday, 23 February 2015 at 23:10:32 UTC, anonymous wrote:
On Monday, 23 February 2015 at 20:21:20 UTC, Charles wrote:
My solution (150 characters, 15 points):
void main(){import std.stdio;int t,n;readf("
%d",&t);while(t--){readf(" %d",&n);real
a=0,i=0;for(;i
Link to problem site:
htt
On Monday, 23 February 2015 at 17:48:27 UTC, Andrei Alexandrescu
wrote:
I used to think the same. But then I considered typechecking
things like:
class Widget
{
private char name[1024];
char[] getName() { return name[]; }
...
}
Such code is safe if Widget is a GC class but not if i
On 24/02/2015 4:33 a.m., Adam D. Ruppe wrote:
On Monday, 23 February 2015 at 05:41:51 UTC, Rikki Cattermole wrote:
Perhaps we could get some UTU students involved with it?
UVU. But will students will be attending too? I think they should be
able to, it would be good exposure to them and give u
On Monday, 23 February 2015 at 15:35:52 UTC, Ola Fosheim Grøstad
wrote:
If you do excessive refcounting (ARC) and care about
performance you actually need to let the implementor of C
decide where the RC_counter is embedded...
C providing facility to be refcountable do not equate with C's
user
On Mon, 23 Feb 2015 23:10:28 +, bitwise wrote:
>> you don't need to. if you really need to do that, you're doing
>> something
>
> This makes no sense to me. A usage example may be helpful.
you still thinking in terms of generators. generator is a high-level
construct, resumable routine is a
On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
This is going to sound really stupid... but do people actually
use
exceptions regularly?
I'd say exception are exceptional in most code. That being said,
unless the compiler can PROVE that no exception is gonna be
thrown, you are stuck
On Mon, 23 Feb 2015 21:11:22 +, Sativa wrote:
> How hard would it be to modify D's GC to do the following two things:
>
> 1. Scan the heap in the BG on another thread/cpu for compactification.
needs read/write barriers added to generated code. a major slowdown for
ALL memory access.
> 2. M
On Monday, 23 February 2015 at 22:11:48 UTC, weaselcat wrote:
On Monday, 23 February 2015 at 21:11:23 UTC, Sativa wrote:
How hard would it be to modify D's GC to do the following two
things:
1. Scan the heap in the BG on another thread/cpu for
compactification.
2. Move blocks of memory in p
Walter Bright:
5. bounds checking
When you go past bounds of a built-in array you get an error
located in the user code, while if you put a pre-condition in
your Array struct to detect the same errors, you get a run-time
error message located in that pre-condition instead. I'd like
some wa
Steve Sobel:
It can get down to 155 using ranges, but those imports really
are killer.
You usually don't want to design a language for code golfing (but
several exist, like http://esolangs.org/wiki/GolfScript ).
void main(){import
std.algorithm,std.conv,std.range,std.stdio;foreach(n;stdin
On 02/23/15 21:21, Charles via Digitalmars-d wrote:
> My solution (150 characters, 15 points):
>
> void main(){import std.stdio;int t,n;readf(" %d",&t);while(t--){readf("
> %d",&n);real a=0,i=0;for(;i
On 2/23/15 2:15 PM, Walter Bright wrote:
This is pretty straightforward.
[snip]
The code builds if you slap a "@safe:" at the top. There is one bug in
the compiler: "delete" must not be allowed in @safe code. The destructor
must be @trusted.
Understanding that this code (sans delete) is @sa
On Monday, 23 February 2015 at 20:21:20 UTC, Charles wrote:
My solution (150 characters, 15 points):
void main(){import std.stdio;int t,n;readf("
%d",&t);while(t--){readf(" %d",&n);real
a=0,i=0;for(;i
Link to problem site:
https://www.hackerrank.com/challenges/leibniz
Anyone care to do
you don't need to. if you really need to do that, you're doing
something
This makes no sense to me. A usage example may be helpful.
resumable functions are not iterators. it's a slightly
perversed flow
control method. iteration/generation is one of the use cases.
So how do you explain enume
On Monday, 23 February 2015 at 21:30:51 UTC, Steven Schveighoffer
wrote:
On 2/23/15 3:21 PM, Charles wrote:
For the uninitiated, Code Golf is producing the correct answer
to a
question with minimal syntax (whitespace included). I found a
couple
questions on HackerRank, which allows D compilatio
I didn't beat your score, but I did it with ranges (full
character count was 174):
stdin.readln();
foreach(x; stdin.byLine)
writefln("%0.15f", map!(a =>
(a&1?-1:1)/(2.0*a+1))(iota(x.to!int)).sum);
I think if I didn't have to import so many things, I would have
done much better :)
-Stev
On Monday, 23 February 2015 at 21:07:04 UTC, George Sapkin wrote:
Seems like there are some local meetups starting across the
globe, but no Dutch one so far. Are there any D users from the
Netherlands that would want to meetup and share their D
stories? Cheers.
I would surely come. Though hav
This is pretty straightforward. More could be done:
1. small array optimization
2. support for ranges as constructor args
3. present a range interface
4. support for malloc/free instead of GC
5. bounds checking
6. the array[] and the count could be allocated together
7. array[] could be just a po
On Monday, 23 February 2015 at 21:11:23 UTC, Sativa wrote:
How hard would it be to modify D's GC to do the following two
things:
1. Scan the heap in the BG on another thread/cpu for
compactification.
2. Move blocks of memory in predictable(timewise) chunks that
prevents locking the main thr
On 2/23/15 5:04 PM, Andrei Alexandrescu wrote:
On 2/23/15 1:30 PM, Steven Schveighoffer wrote:
foreach(x; stdin.byLine)
writefln("%0.15f", map!(a =>
(a&1?-1:1)/(2.0*a+1))(iota(x.to!int)).sum);
Wonder why didn't you lead with the iota? -- Andrei
Cuz that's how it came out my brain ;)
-
On 2/23/15 1:30 PM, Steven Schveighoffer wrote:
foreach(x; stdin.byLine)
writefln("%0.15f", map!(a =>
(a&1?-1:1)/(2.0*a+1))(iota(x.to!int)).sum);
Wonder why didn't you lead with the iota? -- Andrei
On 2/23/15 3:21 PM, Charles wrote:
For the uninitiated, Code Golf is producing the correct answer to a
question with minimal syntax (whitespace included). I found a couple
questions on HackerRank, which allows D compilation. So far there's only
two entries for D (mine and another) for the first p
Basically, I am simply wondering if the GC can "throttle" itself
as to reduce the *maximum* time the program has to wait.
How hard would it be to modify D's GC to do the following two
things:
1. Scan the heap in the BG on another thread/cpu for
compactification.
2. Move blocks of memory in predictable(timewise) chunks that
prevents locking the main thread for any period of time.
e.g., in the first step the GC
On Mon, 23 Feb 2015 20:21:19 +, Charles wrote:
> My solution (150 characters, 15 points):
>
> void main(){import std.stdio;int t,n;readf("
> %d",&t);while(t--){readf(" %d",&n);real
> a=0,i=0;for(;i
> Link to problem site: https://www.hackerrank.com/challenges/leibniz
>
> Anyone care t
Seems like there are some local meetups starting across the
globe, but no Dutch one so far. Are there any D users from the
Netherlands that would want to meetup and share their D stories?
Cheers.
On 2/22/2015 3:25 AM, Jacob Carlborg wrote:
* Most good GC implementations need some kind of barrier (read or write, don't
remember which). If I recall there are several people against this in the
community
Count me among those.
In Java, write barriers make sense because Java uses the GC for
For the uninitiated, Code Golf is producing the correct answer to
a question with minimal syntax (whitespace included). I found a
couple questions on HackerRank, which allows D compilation. So
far there's only two entries for D (mine and another) for the
first problem.
Here's the problem:
In
Urgh. Product types masquerading as sum types. Give me a break
will ya. -- Andrei
1. The product solution is more pleasant to work with, if you
have no sugar for sum types like pattern matching.
2. It's the same as with exception specifications: Product types
make ignoring the error path eas
On 2/21/15 9:27 PM, Peter Alexander wrote:
On Sunday, 22 February 2015 at 01:24:09 UTC, Almighty Bob wrote:
a += b; // Compiles with no ERROR!
Please tell me that's a bug?
Not a bug. From spec:
http://dlang.org/expression.html#AssignExpression
Assignment operator expressions, such as:
a op
Le 23/02/2015 07:13, Olivier Pisano a écrit :
On Sunday, 22 February 2015 at 22:27:42 UTC, Raphaël Jakse wrote:
Le 22/02/2015 14:00, Olivier Pisano a écrit :
I did send you a first draft of the variable number of parameters
chapter on Friday, on your gmail address. Did you get it ?
Yes, I tho
On Mon, 2015-02-23 at 10:29 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> DConf 2015 got a couple of lightning talk proposals. We obviously need a
> few of those to consolidate them into a session. Any more takers? -- Andrei
Let people sign up to do them at the conference. This management
On 2/23/15 10:27 AM, Adam D. Ruppe wrote:
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu wrote:
The typechecker must WHILE COMPILING WIDGET, NOT ITS CLIENT know
whether getName() is okay or not.
Aye, I haven't been following this thread closely, but I thought of this
case a w
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu
wrote:
The typechecker must WHILE COMPILING WIDGET, NOT ITS CLIENT
know whether getName() is okay or not.
Aye, I haven't been following this thread closely, but I thought
of this case a while ago myself and it actually led me to
On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Sunday, 22 February 2015 at 17:01:45 UTC, Andrei Alexandrescu wrote:
On 2/22/15 6:49 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
No. There's also returning the reference from a member function, storing
it in a passed-in reference (
On 2/23/15 3:27 AM, Walter Bright wrote:
On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:
1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in
time and
bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS.
This is
not an option for D.
This is going to sound reall
On 2/22/15 8:50 PM, deadalnix wrote:
On Sunday, 22 February 2015 at 20:48:58 UTC, Andrei Alexandrescu wrote:
What ??? That mean writing all library code twice, for client that want
GC and for these who don't.
I'm not 100% convinced but it seems to me RC vs. GC is a class design
time decision.
On Monday, 23 February 2015 at 15:35:52 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 23 February 2015 at 14:56:11 UTC, Marc Schütz wrote:
violation of the principle of separation of concerns: a
consumer shouldn't need to have information about the
management strategy, it should work equally with
On Monday, 23 February 2015 at 14:56:11 UTC, Marc Schütz wrote:
violation of the principle of separation of concerns: a
consumer shouldn't need to have information about the
management strategy, it should work equally with
`RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it
doesn't tak
On Monday, 23 February 2015 at 05:41:51 UTC, Rikki Cattermole
wrote:
Perhaps we could get some UTU students involved with it?
UVU. But will students will be attending too? I think they should
be able to, it would be good exposure to them and give us some
fresh people too.
On Sunday, 22 February 2015 at 17:01:45 UTC, Andrei Alexandrescu
wrote:
On 2/22/15 6:49 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
No. There's also returning the reference from a member
function, storing
it in a passed-in reference (pointer, ref, out or slice), and
passing it
to other functi
On Monday, 23 February 2015 at 00:03:17 UTC, Andrei Alexandrescu
wrote:
At this point we don't have enough submissions to make DConf
2015 viable. Those we have are of good quality, but simply put
more are needed.
We're counting on our core community (i.e. frequent
contributors to this forum)
Bump !
I'd be interested in helping out with the translation. I call
dibs on the 50th chapter (Member Functions), unless of course
someone is already working on it.
On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
O[…]
This is going to sound really stupid... but do people actually
use
exceptions regularly?
I've never used one. When I encounter code that does, I just
find it
On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
value and error code. C got this fairly wrong, Go gets it
fairly right.
It's the one feature about Go that makes Go code look really
ugly... So I guess this is a very subjective issue. Posix is
actually pretty consistent by ret
On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
> O[…]
> This is going to sound really stupid... but do people actually use
> exceptions regularly?
> I've never used one. When I encounter code that does, I just find it
> really annoying to debug. I've never 'gotten' exceptions. I'm
On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:
1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and
bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is
not an option for D.
This is going to sound really stupid... but do people actually use
exc
On 23 February 2015 at 01:30, Adam D. Ruppe via Digitalmars-d
wrote:
> I could prolly do two talks... especially if someone else wants to suggest a
> topic. Heck, I could improvise in a round table or something too.
I'd happily be on a panel talk. :)
On 23 February 2015 at 20:24, Jakob Ovrum via Digitalmars-d
wrote:
> On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
>>
>> On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
>>
>> wrote:
>>>
>>> On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
I have no idea
On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
wrote:
On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
I have no idea where to start.
Start by making a ref counted type and see what the pain
points are.
All my re
On 23 February 2015 at 16:50, Walter Bright via Digitalmars-d
wrote:
> On 2/22/2015 9:53 PM, Manu via Digitalmars-d wrote:
>>
>> It's got nothing to do with doing work. ARC (or something like it) is
>> almost religiously opposed. We can't even have a reasonable
>> conversation about it, or really
On Monday, 23 February 2015 at 07:19:56 UTC, Paulo Pinto wrote:
Personally I think what matters is getting D's situation
regarding memory management sorted out, regardless out it will
look like in the end.
This is exactly right, either
1. The compiler takes care of allocation/deallocations a
On Monday, 23 February 2015 at 09:01:23 UTC, Daniel Murphy wrote:
"Ola Fosheim Grøstad" " wrote in message
news:hwwotfmkjvwsempqi...@forum.dlang.org...
I mean that the optimizer does not know what _rc is. The
optimizer can only elide what it can prove, by sound logic,
not by assumptions.
Th
"Ola Fosheim Grøstad" " wrote in message
news:hwwotfmkjvwsempqi...@forum.dlang.org...
I mean that the optimizer does not know what _rc is. The optimizer can
only elide what it can prove, by sound logic, not by assumptions.
The whole point of compiler-supported RC is that the optimizer can mak
On Monday, 23 February 2015 at 08:50:28 UTC, Walter Bright wrote:
On 2/23/2015 12:33 AM, Tobias Pankrath wrote:
On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim
Grøstad wrote:
Thanks to the messed up modular arithmetics that D has chosen
you cannot
assume the a non-shared live object do
On Monday, 23 February 2015 at 08:33:59 UTC, Tobias Pankrath
wrote:
You mean when there are more than 2^64 references to the object?
I mean that the optimizer does not know what _rc is. The
optimizer can only elide what it can prove, by sound logic, not
by assumptions.
On Monday, 23 February 2015 at 06:51:21 UTC, Walter Bright wrote:
4. DIP25, now implemented, is a way to address memory safety in
D while using reference counting. Any proposal for ARC needs
to, at least, understand that proposal.
I asked further up in the thread if coroutines can hold onto
"
On 2/23/2015 12:33 AM, Tobias Pankrath wrote:
On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad wrote:
Thanks to the messed up modular arithmetics that D has chosen you cannot
assume the a non-shared live object does not have a rc==0 due to wrapping
integers, in the general case.
On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe
wrote:
On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
All my ref counting types fiddle with the ref in every
assignment, or every function call and return
On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe wrote:
On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
All my ref counting types fiddle with the ref in every
assignment, or every function call and return.
Hmm, the optimizer could potentially tell "inc X; dec X;" is
useless
76 matches
Mail list logo
