Re: Associative Arrays in the data segment
"Andrei Alexandrescu" wrote in message news:mgcqml$2e67$1...@digitalmars.com... This is nice work, but sorry it is hardly conductive to warm fuzzy feelings. -- Andrei It's not ideal, just better than what we have now.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 4/11/15 5:35 AM, matovitch wrote: I am not convinced by the dip77, what about raii managed classes with costly opAssign operator (like in w0rn example) ? The goal of passing an object by reference is to avoid the copy and here you guess the parameter is ref-counted and made a (pseudo-)copy ? Then any allocating opAssign should be marked @system ? Expensive opAssign or expensive postblit? -- Andrei
Re: if(arr) now a warning
On 4/11/15 4:03 AM, w0rp wrote: Having thought about it more, I think that is why we cannot put the range primitives for slices into object.d. Because that makes it impossible to define the primitives differently, so that no auto-decoding occurs. At the moment, auto-decoding isn't part of the language, it's just written in to the standard library. This would change that. That's where it should be. -- Andrei
Re: "make std/concurrency.test" fails but others don't... why?
On 4/11/15 12:25 AM, Vladimir Panteleev wrote: On Friday, 10 April 2015 at 23:04:44 UTC, Andrei Alexandrescu wrote: Martin Nowak added recently a nice feature to the Phobos makefile: by specifying e.g. make std/stdio.test only the unittests for std/stdio.d would build and run. This greatly improves development turnaround for Phobos. FWIW, in most cases you can also do this simply by running: dmd -unittest -main -run stdio.d It won't work if other modules have changed (compared to the dmd in your PATH). The actual command line generated by is: ../dmd/src/dmd -conf= -I../druntime/import -w -dip25 -m64 -g -debug -main -unittest generated/osx/debug/64/libphobos2.a -defaultlib= -debuglib= -L-lcurl -run std/stdio.d So having this in the makefile: * makes sure the library is built automatically * links the right external libs * makes sure command line options such as -dip25 are not omitted * makes sure there's no interference from dmd.conf files * links the correct library * ... So if your point was it can be done just worse, sure. Andrei
Re: Associative Arrays in the data segment
On 4/10/15 8:45 PM, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:mg94od$1v4g$1...@digitalmars.com... Can you make a salient argument that this is a step in the right direction? In that case what's the vision for future steps? Thanks! -- Andrei This approach makes the common cases of AAs in the data segment work. This enables a very useful idiom of defining a constant lookup table and using it at runtime to map values. The hashing and AA implementations that need to be replicated in the compiler are trivial, and easily updated if anybody does change the druntime implementation. At worst it's pretty much a copy-paste from the druntime sources. And as I've said, I'm happy provide a matching dmd implementation of anybody's new druntime implementation. A future library AA implementation would not be complicated by this patch, because the code in this patch is only reached when an AA literal survives until codegen. A library AA would lower the AA literal to some other construct before codegen. This is a step in the right direction because it will make the common cases of this feature work. That's it. It doesn't hurt or help other AA issues in a significant way. This is nice work, but sorry it is hardly conductive to warm fuzzy feelings. -- Andrei
Re: Wiki page: Coming From C++
Thanks for the feedback, I think I've incorporated all the suggested changes. Also added a section on how D deals with object slicing. I can't seem to get the compiler to error on dangling else. I tried the examples in the original PR[1], but they seem to compile without error with DMD 2.067. Is anyone able to make the compiler error on dangling else? [1] https://github.com/D-Programming-Language/dmd/pull/336
Re: Wiki page: Coming From C++
On Saturday, 11 April 2015 at 16:02:53 UTC, David Nadlinger wrote: On Saturday, 11 April 2015 at 10:24:53 UTC, Jakob Ovrum wrote: http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article *Un*signed integer overflow isn't undefined in C/C++ either. — David I removed the section on undefined behaviour for now, I'm not familiar enough with it to really write something convincing. Help would be appreciated.
Re: Mitigating the attribute proliferation - attribute inference for functions
On Sunday, 12 April 2015 at 01:45:16 UTC, Martin Nowak wrote: On 04/12/2015 12:35 AM, weaselcat wrote: How does this differ from e.g, if the function was templated? It doesn't, if you decide to analyze each imported function to perform attribute inference, then that's just like treating all of them like template instances. This approach doesn't scale to bigger projects, because the compiler always has to analyze the complete source code. That's also the reason why an optimization was added to dmd whereby it doesn't instantiate templates, that are already instantiated in an imported module. I thought as much, that's unsettling because dmd is already starting to feel dog slow.
Re: STL and Phobos
On Saturday, 11 April 2015 at 17:14:50 UTC, w0rp wrote: On Saturday, 11 April 2015 at 17:01:42 UTC, Dennis Ritchie wrote: Will the STL included in Phobos or is it impossible? STL won't be included in Phobos, at least as far as I know, but I believe it should be possible to interface to parts of it with extern(C++). To do it, you need to create names for every part of an STL type, including the allocator. Walter discussed all of this in a recent talk. https://www.youtube.com/watch?v=IkwaV6k6BmM It's really more for using existing C++ code which already uses the STL. In terms of algorithms, D is already in a better shape with std.algorithm. In terms of containers, you might find Phobos lacking for the moment, but progress will accelerate when Andrei's allocators are finally included in Phobos. Thanks.
Re: Mitigating the attribute proliferation - attribute inference for functions
On 04/12/2015 12:35 AM, weaselcat wrote: > How does this differ from e.g, if the function was templated? It doesn't, if you decide to analyze each imported function to perform attribute inference, then that's just like treating all of them like template instances. This approach doesn't scale to bigger projects, because the compiler always has to analyze the complete source code. That's also the reason why an optimization was added to dmd whereby it doesn't instantiate templates, that are already instantiated in an imported module.
Re: Which D IDE do you use?(survey)
On Sunday, 12 April 2015 at 01:29:53 UTC, Idan Arye wrote: On Saturday, 11 April 2015 at 22:29:58 UTC, w0rp wrote: On Saturday, 11 April 2015 at 10:27:15 UTC, weaselcat wrote: if you're using vim-dutyl you could just remap K to :DUjump or one of the split variants. (DUddoc also shows the documentation of the symbol under your cursor.) I'll have to try this myself. Vim has a feature for balloon messages, so I was wondering if there was something for that for D in Vim. You can see some examples if you run a Google image search for "vim balloonexpr." Never seen much point in balloonexpr. What's to point of using Vim if I'm gonna use my mouse to do things? balloonexpr is indeed a poor feature, but vim has a lot of those thanks to legacy cruft. One of the reasons I'm excited for(and already use) neovim, implementing something like a cursor-based balloonexpr would be extremely easy.
Re: Which D IDE do you use?(survey)
On Saturday, 11 April 2015 at 22:29:58 UTC, w0rp wrote: On Saturday, 11 April 2015 at 10:27:15 UTC, weaselcat wrote: if you're using vim-dutyl you could just remap K to :DUjump or one of the split variants. (DUddoc also shows the documentation of the symbol under your cursor.) I'll have to try this myself. Vim has a feature for balloon messages, so I was wondering if there was something for that for D in Vim. You can see some examples if you run a Google image search for "vim balloonexpr." Never seen much point in balloonexpr. What's to point of using Vim if I'm gonna use my mouse to do things?
Re: Yes, you can help std.allocator!
On 04/05/2015 05:16 AM, Andrei Alexandrescu wrote: > Right now the allocator design works well as a flexible malloc/free > implementation, but has no support for tracing-based garbage collection. > > I am evaluating whether I should add tracing capabilities to > std.allocator, or stop here. Tracing would most definitely require new > primitives such as embedding some sort of type information and resolving > internal pointers. Just to make sure we're on the same page here. You're talking about implementing the GC in terms of std.allocator, not about making std.allocator GCable, right? This would be fairly interesting for us too experiment with, as we could easily try out different allocator architectures. But then again the GC needs to use highly optimized data structures to lookup metadata, we'll likely only choose a single allocator architecture, and we already know a few good ones https://code.dawg.eu/talks/2015-03-20-garbage_collection_dmeetup/#9. So while the heap layer idea is interesting and would facilitate to try different allocators, it's a substantial amount of work, to add the marking and metadata to std.allocator. We already started to modularize the GC a little and can try out different architectures by hand, so I don't think it's worth the effort. > What would really help this evaluation and any other work on garbage > collection would be a modularization of the tracing process. It's already pretty much like that. http://dlang.org/phobos/core_thread.html#.thread_suspendAll http://dlang.org/phobos/core_thread.html#.thread_scanAll http://dlang.org/phobos/core_thread.html#.thread_resumeAll Scanning is not a range but callback based and misses GC.addRoots and GC.addRanges, wouldn't be too much work to add that. https://github.com/D-Programming-Language/druntime/blob/7877f65a6baf53b0c53c1babf9a0f0a5d1893940/src/gc/gc.d#L2205 There is also no TypeInfo yet. -Martin
Re: Wiki page: Coming From C++
On Saturday, 11 April 2015 at 10:24:53 UTC, Jakob Ovrum wrote: I've done some preliminary work on a wiki page that attempts to convince C++ programmers who are on the fence about D, who need to know what D provides over C++11 and C++14. http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article I don't know if a Coming_From page is the right place for this kind of information. What is the target audience for Coming_From - programmers who are already learning D, or programmers who are investigating D to decide whether or not to try it? If the former, where should we place information for the latter? Contributions to the page are very welcome. I think D's syntax is intuitive enough for C++ programmers that we can use commented D code examples. I could need some help filling up the sections and proposing new sections. Thanks for doing this. Maybe link to Andrei's talks and articles (and Ali's book) on iterators and ranges. Learning D vs investigating whether to try it is not such a binary choice because many people who try a language give up early. Maybe start with the selling points and have a second section below - 'here is how to do stuff'. Some examples, and links to other relevant material.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
On Thursday, 9 April 2015 at 14:03:33 UTC, Dicebot wrote: On Thursday, 9 April 2015 at 04:30:18 UTC, Dicebot wrote: On Wednesday, 1 April 2015 at 20:59:07 UTC, Dicebot wrote: On Wednesday, 1 April 2015 at 20:40:02 UTC, Laeeth Isharc wrote: Experimenting on my oneplusone phone running arch (geekbench3 2.9k) and will be back in range in a week. How much RAM do you think you need? If it is just a PKGBUILD issue - any amount will do. If building ldc itself will be necessary.. well, it can be a bit more demanding :) I hope for the former. Mathias Lang has kindly provided me shell access to one Raspberry, investigating the issue. Seems to work for me now with ldc / liblphobos packages 0.15.1-6 Actual issue was so embarassing that I'd better be silent about it :P Thanks, v much Dicebot. (I think you have earned the right to own up to making simple errors without embarrassment in case you change your mind - it might help someone else to say what it was). Laeeth.
Re: Which D IDE do you use?(survey)
On Saturday, 11 April 2015 at 21:44:08 UTC, Iain Buclaw wrote: No one announced (to me) it's existence. Thanks! I'll be sure to check it out. it also integrates DCD(combined with youcompleteme or similar plugin gives intellisense-like completion,) and dscanner.
Re: Mitigating the attribute proliferation - attribute inference for functions
On Saturday, 11 April 2015 at 21:47:20 UTC, Martin Nowak wrote: Option 1 isn't really viable because it turns into a whole program compilation model. How does this differ from e.g, if the function was templated?
Re: Which D IDE do you use?(survey)
On Saturday, 11 April 2015 at 10:27:15 UTC, weaselcat wrote: if you're using vim-dutyl you could just remap K to :DUjump or one of the split variants. (DUddoc also shows the documentation of the symbol under your cursor.) I'll have to try this myself. Vim has a feature for balloon messages, so I was wondering if there was something for that for D in Vim. You can see some examples if you run a Google image search for "vim balloonexpr."
Re: Mitigating the attribute proliferation - attribute inference for functions
Shouldn't the inference with analysis be possible when you have
the source available at least? You will still have to specify the
attributes in a .di file if you are statically or dynamically
linking to D libraries, but for source libraries or in parts of
your project, you should be able to perform that inference.
That would at the very least reduce attributes to the boundaries
of APIs.
// inferred
private void bar() {}
// inferred
private void baz() {}
@ngoc @safe pure nothrow
public void foo() { bar(); baz(); }
At some point in D, @safe should probably be the default, but
that's a whole problem in itself.
Mitigating the attribute proliferation - attribute inference for functions
Sorry to open yet another topic.
I'm repeatedly finding myself in situations where I write functions like
this.
private @property bool empty() const @safe pure nothrow @nogc
{
return impl is null || !impl.count;
}
This is obviously a joke, because the compiler very well knows the
attributes and I don't need to guarantee them as part of an API.
The situation is getting somewhat out of hands and we need to find a way
to make attribute inference for functions feasible.
At the last D Meetup [¹] I had a nice chat with Dicebot about this.
We both had the same notion of how things should be. People should put
attributes on their exported API functions (or main() for apps), thereby
making API guarantees and transitively enforcing them, but the compiler
should infer attributes for internal functions.
This wouldn't help with separate compilation of modules, because the
compiler only knows the attributes of a function after semantically
analyzing it, but it works extremely well for libraries that are
compiled as batch.
And given that separate compilation is inherently inefficient anyhow,
it's well worth to look at this approach in more detail.
The main problem of attribute inference for functions presents as
follows on API borders.
/// An API function that guarantees certain attributes
public size_t foo(string a) @safe @nogc pure nothrow
{
// and calls an internal function
return impl(a);
}
/// An API template function with the same guarantees
public size_t bar(R)(R a) @safe @nogc pure nothrow
{
// that calls an internal function
return impl("something");
}
/// A function with inferred attributes
private size_t impl(string a)
{
return a.length;
}
Applying attribute inference to `impl` would work for `foo` because code
calling `foo` doesn't need to check the attributes of `impl`, except
when foo gets inlined.
This doesn't work for the template function bar, because attributes are
checked when the template is instantiated, leaving us with the following
options on how the compiler could deal with missing attributes of a
function.
1) If that function has source code available, it gets semantically
analyzed and additional attributes are inferred.
2) The compiler errors because of missing attributes.
3) Don't inline functions when that would require to infer attributes of
a private/package function.
4) ???
Option 1 isn't really viable because it turns into a whole program
compilation model.
Option 2 is basically what we have today. Without a clear border of
where the compiler stops to analyze your implementation details, it'd
still be necessary to annotate every function.
Option 3 defines such a border which allows to use attribute inference
for internal functions. In the above example `bar` wouldn't work without
inference on `impl`, but it's possible to manually annotate the private
functions directly used by a template.
Those ideas aren't thought through too well, but it's an important issue
that requires a solution.
-Martin
[¹]: http://www.meetup.com/Berlin-D-Programmers/events/220702368/
Re: Which D IDE do you use?(survey)
On 11 April 2015 at 12:27, weaselcat via Digitalmars-d wrote: > On Saturday, 11 April 2015 at 10:00:45 UTC, Iain Buclaw wrote: >> >> On 10 April 2015 at 21:19, Adam D. Ruppe via Digitalmars-d >> wrote: >>> >>> On Friday, 10 April 2015 at 19:08:13 UTC, Paulo Pinto wrote: - Move a method to another class located in another module, while updating all references to it, including module imports in the new file >>> >>> >>> >>> Cut the text out of one file, paste it in the new one, compile and fix >>> what >>> the compiler complains about. >>> >>> ...ditto for the others. >>> >>> >>> I admit this takes a few more minutes than an automatic ide thing might, >>> but >>> it isn't that big of a bother to me because the compiler errors combined >>> with vim's "repeat last command" hotkey makes it fairly quick and >>> painless. >>> When I run make from inside vim, it jumps to the file and line the >>> compiler >>> spits out, so I can do a quick "cwnewname" then f4 (my hotkey to go to >>> the >>> next error) and ., repeat until done. >> >> >> Anyone use abbreviations in vim? >> >> One thing that I want to do at some point in time is remap K to goto >> the documentation of a function/method. >> >> Iain. > > > if you're using vim-dutyl you could just remap K to :DUjump or one of the > split variants. > (DUddoc also shows the documentation of the symbol under your cursor.) No one announced (to me) it's existence. Thanks! I'll be sure to check it out.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 09:28:46 UTC, Marc Schütz wrote: It's not acceptable that it happens behind the user's back. Costly operations must be explicit. Nothing is costly here.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 18:20:51 UTC, Marco Leise wrote: Am Fri, 10 Apr 2015 14:04:39 + schrieb "Ola Fosheim Grøstad" : On Friday, 10 April 2015 at 10:28:03 UTC, Walter Bright wrote: > That's what ref counting is about. That would require pervasive ref-counting. You make is sound like there was an alternative to ref counting for resources. Is there? Ownership, GC.
Re: if(arr) now a warning
On 04/11/2015 01:03 PM, w0rp wrote: > At the moment, auto-decoding isn't part of the language That won't change anytime soon.
Re: DIP77 - Fix unsafe RC pass by 'ref'
Am Fri, 10 Apr 2015 14:04:39 + schrieb "Ola Fosheim Grøstad" : > On Friday, 10 April 2015 at 10:28:03 UTC, Walter Bright wrote: > > That's what ref counting is about. > > That would require pervasive ref-counting. You make is sound like there was an alternative to ref counting for resources. Is there? -- Marco
Re: STL and Phobos
On Saturday, 11 April 2015 at 17:01:42 UTC, Dennis Ritchie wrote: Will the STL included in Phobos or is it impossible? STL won't be included in Phobos, at least as far as I know, but I believe it should be possible to interface to parts of it with extern(C++). To do it, you need to create names for every part of an STL type, including the allocator. Walter discussed all of this in a recent talk. https://www.youtube.com/watch?v=IkwaV6k6BmM It's really more for using existing C++ code which already uses the STL. In terms of algorithms, D is already in a better shape with std.algorithm. In terms of containers, you might find Phobos lacking for the moment, but progress will accelerate when Andrei's allocators are finally included in Phobos.
Re: __attribute__((used)) and druntime
On Saturday, 11 April 2015 at 15:59:53 UTC, David Nadlinger wrote: On Saturday, 11 April 2015 at 15:35:47 UTC, w0rp wrote: […] (Also LDC?) in druntime and flag all of the symbols like this appropriately, so that creating executables with gc-sections will Just Work in some cases without a linker script? LDC is shipping with --gc-sections enabled by default since a couple of releases, without a custom linker script. — David Ah. I was also wondering if this was now essentially a solved problem.
STL and Phobos
Will the STL included in Phobos or is it impossible?
Re: __attribute__((used)) and druntime
On Saturday, 11 April 2015 at 15:35:47 UTC, w0rp wrote: From what I just read, __attribute__((used)) in GCC should do the job, and I think it should be usable from GDC with its attribute pragmas. I wouldn't mind having this functionality. For a long time, I've wanted it in C in those cases where I do not have a linker-script or do not have access to a linker-script. In addition to the above, I think it would also be beneficial for those who write hardware/driver libraries for microcontrollers: Just drop in the files that you want to use, then they're linked when found. One could even just work with stand-alone object files marked 'used'.
Re: Wiki page: Coming From C++
On Saturday, 11 April 2015 at 10:24:53 UTC, Jakob Ovrum wrote: http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article *Un*signed integer overflow isn't undefined in C/C++ either. — David
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 04/09/2015 01:10 AM, Walter Bright wrote: > http://wiki.dlang.org/DIP77 It's a very interesting proposal to tackle this specific problem. As with all the scope/lifetime related stuff, I find it extremely difficult to anticipate all the needs and foresee how this will integrate with the rest of the language, or even the other scope related DIPs. At this point it might be better to make a dmd branch and throw up a prototype for all the scope/ref-counted work. The litmus test for a successful design would be safe, efficient, @nogc containers.
Re: __attribute__((used)) and druntime
On Saturday, 11 April 2015 at 15:35:47 UTC, w0rp wrote: […] (Also LDC?) in druntime and flag all of the symbols like this appropriately, so that creating executables with gc-sections will Just Work in some cases without a linker script? LDC is shipping with --gc-sections enabled by default since a couple of releases, without a custom linker script. — David
__attribute__((used)) and druntime
I've been looking into compiling smaller executables, and the trick I learned from watching sessions from the last DConf is to use the KEEP symbol in a linker script with something like gc-sections. So at the compilation stage, symbols are put in different sections, a linker script marks some symbols to be kept if they are not referenced, and then unreferenced symbols are removed, resulting in sometimes very small executables. The problem is that if you don't KEEP some symbols for druntime, or in your own program, you can run into errors because symbols which weren't apparently referenced now get used and your program breaks. I was just thinking, "There must be a GCC extension for doing this without a linker script," I *think* there might be. From what I just read, __attribute__((used)) in GCC should do the job, and I think it should be usable from GDC with its attribute pragmas. I believe there's also an attribute for putting symbols in particular sections. I'm wondering, supposing I'm not completely wrong and this actually works, would it behoove us to add some version() blocks for GDC (Also LDC?) in druntime and flag all of the symbols like this appropriately, so that creating executables with gc-sections will Just Work in some cases without a linker script? What do people think? Am I on to something, or I am just making fanciful ideas which won't work?
Re: Context Sensitive Gui Library
On 12/04/2015 12:32 a.m., jkpl wrote: On Saturday, 11 April 2015 at 09:11:35 UTC, Rikki Cattermole wrote: On 11/04/2015 8:34 p.m., jkpl wrote: On Saturday, 11 April 2015 at 07:28:50 UTC, Rikki Cattermole wrote: On 11/04/2015 7:24 p.m., jkpl wrote: On Saturday, 11 April 2015 at 05:45:10 UTC, Rikki Cattermole wrote: On 11/04/2015 5:43 p.m., Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Thats nice. Now where is the source code? Same here...quite amused. I think that now he's gone in nothern Yukkon to kill the bear whose skin just been sold. Though i might be wrong. I umm, not sure I understand you. it's based on this french idiom: (vendre la peau de l'ours avant de l'avoir tué) in a nutshell: I suspect this announce to be spam because: 1/ googlelize the OP name: nothing, except this post. For such a framework, the guy cannot land from nowhere. 2/ he has posted in te wrong fourm section. 3/ no screenshot, no links. 4/ the concept is quite abstruse, not self-explanatory, no tech details (e.g open-gl for this, xml for that... 5/ it's too providential. Though i might be wrong. Ohhh that. Yeah I understand your pov on this. I just don't like risking alienating somebody who could become part of the D community. I think that if the guy is serious he won't give up because his product is about to be released and he would probably be clever enough to get that my suspicion doesn't matter since i'm just a casual user (casual poster here as well). By the way, after a few investigations and thanks to my hypermnesia, i think that i've spotted him, and if it's the case, the pre-announce is honnest. He might be the author of this other topic: http://forum.dlang.org/thread/yfdaeaduvbqyrjqsq...@forum.dlang.org#post-mailman.3008.1418200191.9932.digitalmars-d:40puremagic.com it was a survey to estimate if it's worth to release a commercial D library. As far as we know, this could be related to Andrei saying that he is expecting a large backer soon. And the fact that we don't know who he is, means that they are not ready to fully announce who they are. Assuming it is valid. Well, will be interesting to see if I'm right in thinking its valid. Would be pretty awesome!
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 11:33:51 UTC, Marc Schütz wrote: On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote: On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: It's not acceptable that it happens behind the user's back. Costly operations must be explicit. Don't know of a better solution. How about this? http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing Btw, I also made other changes: No implied scope for @safe functions, no overloading on scope (instead postblit and destructor are skipped), and added a terminology section (rather important!). Just passing, a bit off topic and clearly not familiar enough with the discussed subject but in case you missed it the last rust blog post is an nice and motivated introduction to their ownership system : http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html I need to read about Marc's scope proposal...I am not convinced by the dip77, what about raii managed classes with costly opAssign operator (like in w0rn example) ? The goal of passing an object by reference is to avoid the copy and here you guess the parameter is ref-counted and made a (pseudo-)copy ? Then any allocating opAssign should be marked @system ?
Re: Context Sensitive Gui Library
On Saturday, 11 April 2015 at 09:11:35 UTC, Rikki Cattermole wrote: On 11/04/2015 8:34 p.m., jkpl wrote: On Saturday, 11 April 2015 at 07:28:50 UTC, Rikki Cattermole wrote: On 11/04/2015 7:24 p.m., jkpl wrote: On Saturday, 11 April 2015 at 05:45:10 UTC, Rikki Cattermole wrote: On 11/04/2015 5:43 p.m., Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Thats nice. Now where is the source code? Same here...quite amused. I think that now he's gone in nothern Yukkon to kill the bear whose skin just been sold. Though i might be wrong. I umm, not sure I understand you. it's based on this french idiom: (vendre la peau de l'ours avant de l'avoir tué) in a nutshell: I suspect this announce to be spam because: 1/ googlelize the OP name: nothing, except this post. For such a framework, the guy cannot land from nowhere. 2/ he has posted in te wrong fourm section. 3/ no screenshot, no links. 4/ the concept is quite abstruse, not self-explanatory, no tech details (e.g open-gl for this, xml for that... 5/ it's too providential. Though i might be wrong. Ohhh that. Yeah I understand your pov on this. I just don't like risking alienating somebody who could become part of the D community. I think that if the guy is serious he won't give up because his product is about to be released and he would probably be clever enough to get that my suspicion doesn't matter since i'm just a casual user (casual poster here as well). By the way, after a few investigations and thanks to my hypermnesia, i think that i've spotted him, and if it's the case, the pre-announce is honnest. He might be the author of this other topic: http://forum.dlang.org/thread/yfdaeaduvbqyrjqsq...@forum.dlang.org#post-mailman.3008.1418200191.9932.digitalmars-d:40puremagic.com it was a survey to estimate if it's worth to release a commercial D library.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote: On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: It's not acceptable that it happens behind the user's back. Costly operations must be explicit. Don't know of a better solution. How about this? http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing Btw, I also made other changes: No implied scope for @safe functions, no overloading on scope (instead postblit and destructor are skipped), and added a terminology section (rather important!).
Re: Wiki page: Coming From C++
On Saturday, 11 April 2015 at 11:02:47 UTC, ponce wrote: You should mention stack variables and members initialized by default. This avoids many release-only bugs. Also: if (cond); // D won't allow that, but C++ will statement(); Almost every C++ programmer encounter this in its carreer. And the improved resolution of name conflicts and the fact order of declaration is by and large not important.
Re: Wiki page: Coming From C++
On Saturday, 11 April 2015 at 10:24:53 UTC, Jakob Ovrum wrote: I've done some preliminary work on a wiki page that attempts to convince C++ programmers who are on the fence about D, who need to know what D provides over C++11 and C++14. http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article I don't know if a Coming_From page is the right place for this kind of information. What is the target audience for Coming_From - programmers who are already learning D, or programmers who are investigating D to decide whether or not to try it? If the former, where should we place information for the latter? Contributions to the page are very welcome. I think D's syntax is intuitive enough for C++ programmers that we can use commented D code examples. I could need some help filling up the sections and proposing new sections. You should mention stack variables and members initialized by default. This avoids many release-only bugs.
Re: Wiki page: Coming From C++
You should mention stack variables and members initialized by default. This avoids many release-only bugs. Also: if (cond); // D won't allow that, but C++ will statement(); Almost every C++ programmer encounter this in its carreer.
Re: if(arr) now a warning
On Friday, 10 April 2015 at 18:32:39 UTC, Andrei Alexandrescu wrote: On 4/10/15 10:28 AM, Steven Schveighoffer wrote: On 4/10/15 11:57 AM, Andrei Alexandrescu wrote: On 4/10/15 6:26 AM, Meta wrote: On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote: Plus, adding arr.empty into object is kind of redundant. The only reason we have arr.empty is so that it becomes a range. -Steve I find it extremely annoying to have to import std.array (or whatever the correct module is) just to use .empty, .front and .popFront on arrays. IMO they should all be in object.d. Yah, I was about to post the same. Range semantics are embedded in the language enough to warrant this. Also empty should work for AAs. How should "abc".front work? Do you want to move unicode decoding of char and wchar arrays into object.d? Serious question, not rhetorical, because I'm not for or against it (except for the notion of changing things for the sake of changing them), I just want to point out what is required. Should decode. Meaning there's no change of semantics, just where the facility is defined. -- Andrei Having thought about it more, I think that is why we cannot put the range primitives for slices into object.d. Because that makes it impossible to define the primitives differently, so that no auto-decoding occurs. At the moment, auto-decoding isn't part of the language, it's just written in to the standard library. This would change that.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 10:14:00 UTC, w0rp wrote: I think the one thing in the DIP I'm not sure of is the definition of what is a reference counted object. I believe it's still defined by DIP74? http://wiki.dlang.org/DIP74
Re: Which D IDE do you use?(survey)
On Saturday, 11 April 2015 at 10:00:45 UTC, Iain Buclaw wrote: On 10 April 2015 at 21:19, Adam D. Ruppe via Digitalmars-d wrote: On Friday, 10 April 2015 at 19:08:13 UTC, Paulo Pinto wrote: - Move a method to another class located in another module, while updating all references to it, including module imports in the new file Cut the text out of one file, paste it in the new one, compile and fix what the compiler complains about. ...ditto for the others. I admit this takes a few more minutes than an automatic ide thing might, but it isn't that big of a bother to me because the compiler errors combined with vim's "repeat last command" hotkey makes it fairly quick and painless. When I run make from inside vim, it jumps to the file and line the compiler spits out, so I can do a quick "cwnewname" then f4 (my hotkey to go to the next error) and ., repeat until done. Anyone use abbreviations in vim? One thing that I want to do at some point in time is remap K to goto the documentation of a function/method. Iain. if you're using vim-dutyl you could just remap K to :DUjump or one of the split variants. (DUddoc also shows the documentation of the symbol under your cursor.)
Wiki page: Coming From C++
I've done some preliminary work on a wiki page that attempts to convince C++ programmers who are on the fence about D, who need to know what D provides over C++11 and C++14. http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article I don't know if a Coming_From page is the right place for this kind of information. What is the target audience for Coming_From - programmers who are already learning D, or programmers who are investigating D to decide whether or not to try it? If the former, where should we place information for the latter? Contributions to the page are very welcome. I think D's syntax is intuitive enough for C++ programmers that we can use commented D code examples. I could need some help filling up the sections and proposing new sections.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 09:28:46 UTC, Marc Schütz wrote:
On Friday, 10 April 2015 at 23:12:55 UTC, deadalnix wrote:
On Friday, 10 April 2015 at 10:02:01 UTC, Martin Nowak wrote:
On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright
wrote:
http://wiki.dlang.org/DIP77
So someone passes an RCO via ref to avoid the inc/dec, and
because that imposes safety issues we turn it into some sort
of pass by value under the hood, defeating the purpose, and
provide an opt-out via @system opAssign.
Wouldn't it more straightforward to make pass-by-ref unsafe
(@system) for RCOs?
Then the only thing missing to make this equally powerful,
would be an optimization opportunity for the compiler to
elide copies of pass-by-value RCOs, e.g. it could avoid
calling the postblit when the function retains the refcount.
Only the first pass by ref create a copy. You can then pass
the ref down all you want without copy.
That is an acceptable cost IMO.
It's not acceptable that it happens behind the user's back.
Costly operations must be explicit.
If we somehow know for a fact that the object really is a
reference counted object, then the cost should be acceptable.
Running the postblit will consist of incrementing a reference
count and nothing else. There's no other way I can think of that
permits passing the object safely.
I think the one thing in the DIP I'm not sure of is the
definition of what is a reference counted object. Say you write
this.
struct Widget {
byte* data;
size_t length;
@trusted
opAssign(ref const(Widget) other) {
length = other.length;
data = malloc(length);
memcpy(cast(void*) data, cast(void*) other.data, length);
}
@trusted
this(this) {
auto oldData = data;
data = malloc(length);
memcpy(cast(void*) data, cast(void*) oldData, length);
}
@trusted
~this() {
free(data);
}
}
Why would you want to do this? Who knows. According to DIP77 the
object above is defined to be a reference counted object, when it
isn't. If we're rejecting the C++ answer of "don't write code
that way," then the same rejection should apply here. We need to
be able to say with 100% certainty that we are dealing with a
reference counted object, or at least an object where we know the
postblit is so trivial the cost of calling it will be small.
Re: Which D IDE do you use?(survey)
On 10 April 2015 at 21:19, Adam D. Ruppe via Digitalmars-d wrote: > On Friday, 10 April 2015 at 19:08:13 UTC, Paulo Pinto wrote: >> >> - Move a method to another class located in another module, while updating >> all references to it, including module imports in the new file > > > Cut the text out of one file, paste it in the new one, compile and fix what > the compiler complains about. > > ...ditto for the others. > > > I admit this takes a few more minutes than an automatic ide thing might, but > it isn't that big of a bother to me because the compiler errors combined > with vim's "repeat last command" hotkey makes it fairly quick and painless. > When I run make from inside vim, it jumps to the file and line the compiler > spits out, so I can do a quick "cwnewname" then f4 (my hotkey to go to the > next error) and ., repeat until done. Anyone use abbreviations in vim? One thing that I want to do at some point in time is remap K to goto the documentation of a function/method. Iain.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 08:35:18 UTC, Ola Fosheim Grøstad wrote: On Friday, 10 April 2015 at 15:44:32 UTC, Andrei Alexandrescu wrote: We hope to do better than Rust. -- Andrei Hope does not cut it. A design that breaks down even on a linked list (e.g. you have to turn to ref-counted pointers everywhere) and that makes findByRef(container,node) break should not have made it to a DIP in the first place. a bidirectional linked list cannot be implemented in safe rust afaik
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: It's not acceptable that it happens behind the user's back. Costly operations must be explicit. Don't know of a better solution.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 4/11/2015 2:18 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote:
On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
On 4/10/2015 11:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote:
Example:
void foo() @safe {
RCArray!int arr = [0,1,2];
{
int* p = &arr[0]; // legal under new scope rules
This would be a bad design of an RCO. RCO's must be constructed to not allow
pointers to the payload other than by ref.
There is no reason for this restriction.
The reason is to prevent unsafe access of the payload.
But if this is your opinion, why did
you agree to "implement 'scope' and 'return' for arrays, classes, and pointers"?
http://forum.dlang.org/post/mfhkbm$2vbk$1...@digitalmars.com
It makes no sense to implement that, but not allow it to be used safely.
In your example posted upthread, it wasn't safe. Perhaps scoped pointers can't
be made safe for RCOs, or perhaps the proposal needs more thinking. I don't know
at the moment.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Friday, 10 April 2015 at 23:12:55 UTC, deadalnix wrote: On Friday, 10 April 2015 at 10:02:01 UTC, Martin Nowak wrote: On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP77 So someone passes an RCO via ref to avoid the inc/dec, and because that imposes safety issues we turn it into some sort of pass by value under the hood, defeating the purpose, and provide an opt-out via @system opAssign. Wouldn't it more straightforward to make pass-by-ref unsafe (@system) for RCOs? Then the only thing missing to make this equally powerful, would be an optimization opportunity for the compiler to elide copies of pass-by-value RCOs, e.g. it could avoid calling the postblit when the function retains the refcount. Only the first pass by ref create a copy. You can then pass the ref down all you want without copy. That is an acceptable cost IMO. It's not acceptable that it happens behind the user's back. Costly operations must be explicit.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Saturday, 11 April 2015 at 09:15:19 UTC, Martin Nowak wrote: On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote: This would be a bad design of an RCO. RCO's must be constructed to not allow pointers to the payload other than by ref. And taking the address of that is already unsafe. It isn't under my proposal, which Walter has already accepted the most important part of.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
On 4/10/2015 11:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
Example:
void foo() @safe {
RCArray!int arr = [0,1,2];
{
int* p = &arr[0]; // legal under new scope rules
This would be a bad design of an RCO. RCO's must be constructed
to not allow pointers to the payload other than by ref.
There is no reason for this restriction. But if this is your
opinion, why did you agree to "implement 'scope' and 'return' for
arrays, classes, and pointers"?
http://forum.dlang.org/post/mfhkbm$2vbk$1...@digitalmars.com
It makes no sense to implement that, but not allow it to be used
safely.
Re: DIP77 - Fix unsafe RC pass by 'ref'
I was thinking about this again, and how the first 'ref' would
create a copy in order to keep the object around. At first I
thought I didn't like that, but then I realised that it's
actually not far from what I wanted for taking r-values by
reference. I commonly write functions which take values either by
reference or by value in this way.
void foo(ref T value);
void foo(T value) { foo(value); }
Which obviously results in a combinatorial explosion of
overloads, which you can write automatically some times with
'auto ref'.
My question is, in the greater context of the language, supposing
we had this copying behaviour for a first ref for reference
counted objects, will it putting something in the language for
copying r-values into functions, or will it provide a path to
implement such a thing?
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote: This would be a bad design of an RCO. RCO's must be constructed to not allow pointers to the payload other than by ref. And taking the address of that is already unsafe.
Re: Context Sensitive Gui Library
On 11/04/2015 8:34 p.m., jkpl wrote: On Saturday, 11 April 2015 at 07:28:50 UTC, Rikki Cattermole wrote: On 11/04/2015 7:24 p.m., jkpl wrote: On Saturday, 11 April 2015 at 05:45:10 UTC, Rikki Cattermole wrote: On 11/04/2015 5:43 p.m., Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Thats nice. Now where is the source code? Same here...quite amused. I think that now he's gone in nothern Yukkon to kill the bear whose skin just been sold. Though i might be wrong. I umm, not sure I understand you. it's based on this french idiom: (vendre la peau de l'ours avant de l'avoir tué) in a nutshell: I suspect this announce to be spam because: 1/ googlelize the OP name: nothing, except this post. For such a framework, the guy cannot land from nowhere. 2/ he has posted in te wrong fourm section. 3/ no screenshot, no links. 4/ the concept is quite abstruse, not self-explanatory, no tech details (e.g open-gl for this, xml for that... 5/ it's too providential. Though i might be wrong. Ohhh that. Yeah I understand your pov on this. I just don't like risking alienating somebody who could become part of the D community.
Re: Which D IDE do you use?(survey)
On 2015-04-10 21:02, Idan Arye wrote: Many of these Vim users are not really Vim users - not in the sense that Emacs users are Emacs users anyways. Sure, they use Vim - but only because it's a default editor in Unix-like systems. If Windows Notepad was the default text they wouldn't have installed Vim so they could use it - they simply would have used Notepad. They just want something that'll allow them to edit text files, and they don't care to learn anything more advanced than the most basic stuff they need - opening it from the shell to edit a file, typing text, saving, closing. Other simple commands - like opening another file in the same session - might also be basic and simple, but because they are not part of that workflow these users won't bother to learn them. I wouldn't call those Vim users, even I can do that. But that is only because sometimes I need to SSH in to a computer and edit a file that doesn't provide anything other than Vim. -- /Jacob Carlborg
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Friday, 10 April 2015 at 15:44:32 UTC, Andrei Alexandrescu wrote: We hope to do better than Rust. -- Andrei Hope does not cut it. A design that breaks down even on a linked list (e.g. you have to turn to ref-counted pointers everywhere) and that makes findByRef(container,node) break should not have made it to a DIP in the first place. D needs clean semantics on what is a value. The only sensible definition for a copyable value is that you cannot take the identity in _any way_ from a value or anything that can be reached from it. D needs clean semantics on what is unique ownership. Ref counting is not it. Pervasive ref counting requires WPO to work out ok. C++14 with sanitizer tooling is a lot more attractive than this direction you are going for.
Re: Context Sensitive Gui Library
On Saturday, 11 April 2015 at 07:28:50 UTC, Rikki Cattermole wrote: On 11/04/2015 7:24 p.m., jkpl wrote: On Saturday, 11 April 2015 at 05:45:10 UTC, Rikki Cattermole wrote: On 11/04/2015 5:43 p.m., Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Thats nice. Now where is the source code? Same here...quite amused. I think that now he's gone in nothern Yukkon to kill the bear whose skin just been sold. Though i might be wrong. I umm, not sure I understand you. it's based on this french idiom: (vendre la peau de l'ours avant de l'avoir tué) in a nutshell: I suspect this announce to be spam because: 1/ googlelize the OP name: nothing, except this post. For such a framework, the guy cannot land from nowhere. 2/ he has posted in te wrong fourm section. 3/ no screenshot, no links. 4/ the concept is quite abstruse, not self-explanatory, no tech details (e.g open-gl for this, xml for that... 5/ it's too providential. Though i might be wrong.
Re: Context Sensitive Gui Library
On Saturday, 11 April 2015 at 05:43:14 UTC, Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Github + code.dlang.org
Re: "make std/concurrency.test" fails but others don't... why?
On Friday, 10 April 2015 at 23:04:44 UTC, Andrei Alexandrescu wrote: Martin Nowak added recently a nice feature to the Phobos makefile: by specifying e.g. make std/stdio.test only the unittests for std/stdio.d would build and run. This greatly improves development turnaround for Phobos. FWIW, in most cases you can also do this simply by running: dmd -unittest -main -run stdio.d It won't work if other modules have changed (compared to the dmd in your PATH).
Re: Context Sensitive Gui Library
On 11/04/2015 7:24 p.m., jkpl wrote: On Saturday, 11 April 2015 at 05:45:10 UTC, Rikki Cattermole wrote: On 11/04/2015 5:43 p.m., Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Thats nice. Now where is the source code? Same here...quite amused. I think that now he's gone in nothern Yukkon to kill the bear whose skin just been sold. Though i might be wrong. I umm, not sure I understand you.
Re: Context Sensitive Gui Library
On Saturday, 11 April 2015 at 05:45:10 UTC, Rikki Cattermole wrote: On 11/04/2015 5:43 p.m., Rashad Vinshy wrote: CSGL: I would like to announce the release of my beta library for D! What is the best plan of action at this point to contribute it to the D community? (the library still needs debugging and optimization support, I've only tested it on my machine) For those interested the library hast he following features currently supported: 1. CSGL exists on a series of overlays over the workspace - by simply design one can simulate traditional gui's. 2. CSGL has context sensitive capabilities - Allows one to change the gui depending on what actions have previously taken place. 3. CSGL is intelligent and can find optimal patterns in your work flow. You are presented with what you need at that point. The self modifying gui can adapt not only visual elements but also context sensitive hotkeys, mouse interact, and even things such as MIDI, OSC, COM, etc. 4. CSGL has a built in fully capable scripting editor. One can not only write their on wrappers around the gui elements but also design commonly used macros to reduce complex gui interaction tasks. One can even do such things as animation using the scripting language 5. CSGL has pluggable modules that can be freely used by any gui that recognizes them. One can also access them through scripting. 6. The visual template of the gui can be easily changed through the gui template library. (your apps can be reskinned by a few clicks) 7. Full multi-monitor support, including automatically tracking usage patterns to present the user with the best possible scenario. 8. Full User-Edit mode. By a special hotkey the user can go into edit mode and configure and edit the different gui elements. The same editor is used to the design the gui. Features to come: Full GUI editor(not done yet). Something like Blend. -- Next week I will be able to upload a working demo that shows off some of the capabilities; Some of the graphics treats such as alpha channel tricks, along with how context sensitive gui's work. The demo is a graphics program that essentially changes the gui as you change your working actions. If you use the paintbrush tool, not only do the other tools reorder themselves, they also can(but not necessarily) configure themselves to present to you similar choices that were used before in similar contexts. In this case(of a new user) a circular swatch is present to the user that surrounds the canvas for easy color access that is on it's own overlay along with the right mouse button becoming a different function(from a secondary drawing tool function to an eraser. This was done by scripting side to show how it can be used). Also, If anyone is interested in helping with this project please let me know. Thanks, RV Thats nice. Now where is the source code? Same here...quite amused. I think that now he's gone in nothern Yukkon to kill the bear whose skin just been sold. Though i might be wrong.
