Re: Ropes (concatenation trees) for strings in D ?
On Saturday, 16 August 2014 at 02:26:29 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 15 Aug 2014 19:04:10 -0700 Timothee Cour via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: sounds like my C library based on this article: http://e98cuenc.free.fr/wordprocessor/piecetable.html i'm slowly converting my C code to D (nothing fancy yet, still C-style). it's not a 'real' rope -- it's designed for text editing tasks, and it allocates like crazy now, but it's pretty usable to writing rich text editors and renderers in various GUI toolkits. don't know when i'll finish first working version though, it's all little tedious and i have alot other things to do. but i'll announce it when it will be done. ;-) I've done some progress on making piece table some time ago, but have no time atm. Have a look https://github.com/MrSmith33/textedit-d It supports inserting, removing, undo, redo and slicing. Provides forward range interface. Can you also share your progress?
Re: Ropes (concatenation trees) for strings in D ?
On Sat, 16 Aug 2014 10:25:01 + MrSmith via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Can you also share your progress? sure. the project has no public repo yet, but you can take a look at it's current state here: http://ketmar.no-ip.org/etx.txz no undo/redo support for now, and it accepts only dchars, but you can find working (i hope, at least unittests works ;-) rb-tree and piecetable there. no slicing yet, and range support is nearly non-existing, but piecetable supports extensible text styles! ;-) i'm not really happy with design though. it mindlessly allocates alot of small classes (it should use pools instead, i believe) and high-level text rendering interface is not ported yet. i'm planning to announce it in d.announces when it will be ready to 'go public'. not sure yet if i'll leave it 'as is' or will try to rewrite in in something like 'D style' before announcing. ah, and it needs at least minimal documentation too. ;-) signature.asc Description: PGP signature
Re: @safe, pure and nothrow at the beginning of a module
If I understand correctly Adam Ruppe's Cookbook, by putting @safe: pure: nothrow: at the beginning of a module, I distribute it on all definitions, right? Even methods, inner classes, and so on? I read Adam's book again and I was wrong: Chapter 7, p. 173: You may add @safe: to the top of your module and aggregate definitions to apply the annotation to all function that follows, instead of writing it on each individual function. So, first, he's talking only about @safe (though I suppose it works the same for all annotations) and he says: *and aggregate definitions*. We indeed need to put annotations inside aggregates to affect their innards. If that's true, I have a lot of annotation sprinkling to do.
Re: @safe, pure and nothrow at the beginning of a module
On 08/16/14 13:18, Philippe Sigaud via Digitalmars-d-learn wrote: We indeed need to put annotations inside aggregates to affect their innards. If that's true, I have a lot of annotation sprinkling to do. It's not true for @safe, but true for some other attributes. http://forum.dlang.org/post/mailman.125.1397731134.2763.digitalmar...@puremagic.com artur
Re: @safe, pure and nothrow at the beginning of a module
On Sat, Aug 16, 2014 at 1:30 PM, Artur Skawina via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 08/16/14 13:18, Philippe Sigaud via Digitalmars-d-learn wrote: We indeed need to put annotations inside aggregates to affect their innards. If that's true, I have a lot of annotation sprinkling to do. It's not true for @safe, but true for some other attributes. http://forum.dlang.org/post/mailman.125.1397731134.2763.digitalmar...@puremagic.com Okay... So @safe includes child scopes. I suppose @trusted and @system work in the same way. *but* nothrow, @nogc and UDA's do not include child scopes. Putting them at the beginning of a module will not affect methods in aggregates... What's the situation for pure? (I don't have a D compiler handy right now, or I would test it myself).
Re: @safe, pure and nothrow at the beginning of a module
On 08/16/14 13:58, Philippe Sigaud via Digitalmars-d-learn wrote: On Sat, Aug 16, 2014 at 1:30 PM, Artur Skawina via Digitalmars-d-learn http://forum.dlang.org/post/mailman.125.1397731134.2763.digitalmar...@puremagic.com Okay... So @safe includes child scopes. I suppose @trusted and @system work in the same way. *but* nothrow, @nogc and UDA's do not include child scopes. Putting them at the beginning of a module will not affect methods in aggregates... What's the situation for pure? (I don't have a D compiler handy right now, or I would test it myself). @safe, @trusted, @system, shared, immutable, const, inout and `extern (...)` affect child scopes. `synchronized` does too, but in a rather unintuitive way; hopefully nobody uses this. ;) Other attributes, including 'pure' and 'nothrow' only affect symbols in the current scope. artur
Re: extern (c++) std::function?
On 2014-08-15 6:12 AM, Rémy Mouëza wrote: assignments of anonymous/inline ones. You may want to add a layer of abstraction to the API you expose in D so that user D delegates are used from a second extern (C) delegate itself used by the C++ wrapper: Thanks for the detailed answer, this is the direction I'm going to be taking!
Re: @safe, pure and nothrow at the beginning of a module
Artur: @safe, @trusted, @system, shared, immutable, const, inout and `extern (...)` affect child scopes. `synchronized` does too, but in a rather unintuitive way; hopefully nobody uses this. ;) Well, I also hope no one uses inout: at the module level? Other attributes, including 'pure' and 'nothrow' only affect symbols in the current scope. There we are. Good to know, thanks.
Re: core.thread.Fiber --- runtime stack overflow unlike goroutines
On Friday, 15 August 2014 at 22:26:54 UTC, ketmar via Digitalmars-d-learn wrote: and we -- 32-bit addicts -- will run out of address space while 64-bit happy people will laugh looking at us. ;-) You should only choose stack size carefully or keep data in TempAlloc instead of stack.
Re: @safe, pure and nothrow at the beginning of a module
On Sat, 16 Aug 2014 14:39:00 +0200 Artur Skawina via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 08/16/14 13:58, Philippe Sigaud via Digitalmars-d-learn wrote: On Sat, Aug 16, 2014 at 1:30 PM, Artur Skawina via Digitalmars-d-learn http://forum.dlang.org/post/mailman.125.1397731134.2763.digitalmar...@puremagic.com Okay... So @safe includes child scopes. I suppose @trusted and @system work in the same way. *but* nothrow, @nogc and UDA's do not include child scopes. Putting them at the beginning of a module will not affect methods in aggregates... What's the situation for pure? (I don't have a D compiler handy right now, or I would test it myself). @safe, @trusted, @system, shared, immutable, const, inout and `extern (...)` affect child scopes. `synchronized` does too, but in a rather unintuitive way; hopefully nobody uses this. ;) Other attributes, including 'pure' and 'nothrow' only affect symbols in the current scope. It sounds like a bug to me if they're not consistent. - Jonathan M Davis
Re: @safe, pure and nothrow at the beginning of a module
On Saturday, 16 August 2014 at 19:30:16 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: On Sat, 16 Aug 2014 14:39:00 +0200 Artur Skawina via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 08/16/14 13:58, Philippe Sigaud via Digitalmars-d-learn wrote: On Sat, Aug 16, 2014 at 1:30 PM, Artur Skawina via Digitalmars-d-learn http://forum.dlang.org/post/mailman.125.1397731134.2763.digitalmar...@puremagic.com Okay... So @safe includes child scopes. I suppose @trusted and @system work in the same way. *but* nothrow, @nogc and UDA's do not include child scopes. Putting them at the beginning of a module will not affect methods in aggregates... What's the situation for pure? (I don't have a D compiler handy right now, or I would test it myself). @safe, @trusted, @system, shared, immutable, const, inout and `extern (...)` affect child scopes. `synchronized` does too, but in a rather unintuitive way; hopefully nobody uses this. ;) Other attributes, including 'pure' and 'nothrow' only affect symbols in the current scope. It sounds like a bug to me if they're not consistent. - Jonathan M Davis Well, you got @system to override @safe, but no @impure or @throws. So the behavior can kind of make sense in a way. Maybe.
Re: drop* and take* only for specific element values
On Thursday, 14 August 2014 at 07:30:59 UTC, Nordlöw wrote: On Thursday, 14 August 2014 at 00:56:47 UTC, Jonathan M Davis wrote: You forgot the !, making the predicate a function argument. It Great! My solution: Depending on your exact needs, don't forget too about findSkip (same as find, but skips found element), as well as filter. In particular, r.filter!pred.take(N) would give you a (lazy) range consisting of the first 10 elements in r that verify pred. In some cases, until could also suit your needs. Long story short, D range and algorithms are little building blocks. There aren't that many basic functions that can't simply be expressed as a combination of already existing blocks.
Re: String Prefix Predicate
On Thursday, 14 August 2014 at 17:41:08 UTC, Nordlöw wrote: On Thursday, 14 August 2014 at 17:33:41 UTC, Justin Whear wrote: std.algorithm.startsWith? Should auto-decode, so it'll do a What about https://github.com/D-Programming-Language/phobos/pull/2043 Auto-decoding should be avoided when possible. I guess something like whole.byDchar().startsWith(part.byDchar()) is preferred right? I don't get it? If you use byDchar, you are *explicitly* decoding. How is that any better? If anything, you are *preventing* the (many) opportunities phobos has to *avoid* decoding when it can... If you really want to avoid decoding, use either representation which will do char[] = ubyte[] conversion, or byCodeUnit, which will create a range that returns single elements (IMO, byCodeUnit should be prefered over byChar, as it infers the correct width).
Re: String Prefix Predicate
On Saturday, 16 August 2014 at 20:59:47 UTC, monarch_dodra wrote: If anything, you are *preventing* the (many) opportunities phobos has to *avoid* decoding when it can... By that I want to stress what Jonathan M Davis said Unless the string types match, there's no way around it. You should absolutely realize that that means that when the string types (widths) *do* match, then search (which includes all flavors in phobos) will NOT decode. Heck, if you do a string, element search, eg find(my phrase, someDchar), then phobos will *encode* someDchar into a correctly sized string, and then do a full non-decoding string-string search, which is actually much faster than the naive decoding search.
Re: @safe, pure and nothrow at the beginning of a module
On Saturday, 16 August 2014 at 20:48:25 UTC, monarch_dodra wrote: On Saturday, 16 August 2014 at 19:30:16 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: On Sat, 16 Aug 2014 14:39:00 +0200 Artur Skawina via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: @safe, @trusted, @system, shared, immutable, const, inout and `extern (...)` affect child scopes. `synchronized` does too, but in a rather unintuitive way; hopefully nobody uses this. ;) Other attributes, including 'pure' and 'nothrow' only affect symbols in the current scope. It sounds like a bug to me if they're not consistent. - Jonathan M Davis Well, you got @system to override @safe, but no @impure or @throws. So the behavior can kind of make sense in a way. Maybe. Except that attributes like const, immutable, shared, and inout can't be reversed either (in fact @system, @trusted, and @safe - and maybe extern - are the only ones from that list that can be, so while I could see making that separation, that's not what's actually happening. - Jonathan M Davis
GC can collect object allocated in function, despite a pointer to the object living on?
Hello, I've been interested in the D language for a few years
now, but only dabble. I have read TDPL and recently started
reading D Cookbook. On the side, I started to write a small game
in D, but ran into a problem. I would greatly appreciate any help!
My design is a simple state machine. I have a module game.states,
which includes:
interface IState{
void handleEvents();
void renderFrame();
}
IState *currentState;
string nextState;
void changeState(){
if(nextState != WaitState nextState != ExitState){
auto newState = cast(IState)
Object.factory(game.states.~nextState);
import std.exception;
enforce(newState);
currentState = newState;
nextState = WaitState;
}
}
class TitleState : IState{
void handleEvents(){
...
}
void renderFrame(){
...
}
}
...
}
and the game loop is of the following form:
//init state
nextState = TitleState;
changeState();
//game loop
while(nextState != ExitState){
currentState.handleEvents();
currentState.renderFrame();
changeState();
}
However, it appears that the changeState function has a bug.
I believe the problem is that when changeState returns, newState
gets garbage collected, despite currentState pointing to it.
I come from a C++ background, so I am not used to garbage
collection.
Normally the changeState function would explicitly free the old
state, and allocate the new one.
Am I correct that newState is liable to be collected after
changeState returns?
Is there an easy fix?
Is my design fundamentally flawed within the context of garbage
collection?
If so, what kind of design would you recommend instead?
Re: GC can collect object allocated in function, despite a pointer to the object living on?
Interface and object variables are reference types--you don't need the '*' to make them so. By adding the extra layer of indirection you're losing the only reference the GC can decipher to the currentState instance.
Re: GC can collect object allocated in function, despite a pointer to the object living on?
On Saturday, 16 August 2014 at 22:36:51 UTC, 岩倉 澪 wrote:
void changeState(){
if(nextState != WaitState nextState != ExitState){
auto newState = cast(IState)
Object.factory(game.states.~nextState);
import std.exception;
enforce(newState);
// !!!
currentState = newState;
// !!!
nextState = WaitState;
}
}
However, it appears that the changeState function has a bug.
I believe the problem is that when changeState returns, newState
gets garbage collected, despite currentState pointing to it.
I come from a C++ background, so I am not used to garbage
collection.
Normally the changeState function would explicitly free the old
state, and allocate the new one.
Am I correct that newState is liable to be collected after
changeState returns?
Is there an easy fix?
Is my design fundamentally flawed within the context of garbage
collection?
If so, what kind of design would you recommend instead?
This is actually not garbage collection. newState is making a
pointer to a reference that is located on the stack (that is,
when you return from that function
you now have a pointer that may at any time become overwritten
and made invalid.)
As it turns out, interfaces/classes in D are already reference
types, so you can just do something like this:
IState currentState; // reference to an IState
void changeState(){
if(nextState != WaitState nextState != ExitState){
auto newState = cast(IState)
Object.factory(game.states.~nextState);
import std.exception;
enforce(newState);
currentState = newState; // changed
nextState = WaitState;
}
}
Re: GC can collect object allocated in function, despite a pointer to the object living on?
Thank you for the help! I just removed the unnecessary indirection and it is working great! I was aware that interface and object variables are reference types, but it slipped my mind. I'm too used to the C++ way of things still :p On Saturday, 16 August 2014 at 22:41:45 UTC, Sean Kelly wrote: Interface and object variables are reference types--you don't need the '*' to make them so. By adding the extra layer of indirection you're losing the only reference the GC can decipher to the currentState instance.
Re: GC can collect object allocated in function, despite a pointer to the object living on?
I see now, makes sense. :) On Saturday, 16 August 2014 at 22:43:21 UTC, Chris Cain wrote: This is actually not garbage collection. newState is making a pointer to a reference that is located on the stack (that is, when you return from that function you now have a pointer that may at any time become overwritten and made invalid.)
Re: core.thread.Fiber --- runtime stack overflow unlike goroutines
On Sat, 16 Aug 2014 17:49:28 + Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You should only choose stack size carefully or keep data in TempAlloc instead of stack. but i can choose stack size carefully without such 'address reserving' feature. ;-) signature.asc Description: PGP signature
Re: @safe, pure and nothrow at the beginning of a module
On Sat, 16 Aug 2014 20:48:23 + monarch_dodra via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Well, you got @system to override @safe, but no @impure or @throws. So the behavior can kind of make sense in a way. Maybe. talking about attributes. the unability to reverse 'final:' makes me mad. i'm almost ready to patch the compiler myself and start using this feature even if it will be never accepted in mainline, like i'm doing now with 'foreach (auto i; ...)'. signature.asc Description: PGP signature
Re: Ropes (concatenation trees) for strings in D ?
On Sat, 16 Aug 2014 10:25:01 + MrSmith via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Can you also share your progress? here is public repo: http://repo.or.cz/w/etx.d.git remember, this is not even alpha-quality code (but it seems to be stable enough to build something upon it). API sux, no docs and so on. enjoy. GPLv3. signature.asc Description: PGP signature
