Re: Documentation for any* dub package, any version
On Monday, 26 February 2018 at 14:59:07 UTC, Adam D. Ruppe wrote: Many of you will already know this from the other thread or from my twitter, but I just added a on-demand downloader to my dpldocs.info domain to fetch and build docs for any* dub Would be cool if you could add support for creating docs from any dub project stored on github and not only the ones on code.dlang.org. e.g. create docs for https://github.com/anton-dutov/db: http://githubdoc.dpldocs.info/anton-dutov/db/v6.0.22/db.html or something like that.
Re: Interpolated strings
On Wednesday, 19 April 2017 at 14:02:43 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 12:10:33 UTC, Jonas Drewsen
wrote:
On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen
wrote:
What about supporting an optional prefix inside the {} like:
int year = 2017;
format($"The date is {%04d year}");
so if there is a % immediately following the { then the
chars until next whitespace is format specifier. You can of
course leave out the format specifier and it will default to
%s.
I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `
As mentioned before it is only because it is such a common
pattern that it justifies the change. Seems like many other
languages reached that conclusion as well.
Also take a look at a more realistic example with some more
formatting and it will be more obvious (at least to me it is
:) )
"The date is " ~ format("%04d", year)) ~ " and " ~ user ~ "
just logged into " ~ here;
$"The date is {%04d year} and {user} just logged into {here}"
I see.
So you want to build format strings as well.
This is going to be nasty, and likely to complex for a robust
implementation.
Here is what I would support:
String interpolation literals can only be used with strings.
And they need to start with some prefix which is not an
operator.
I"The date is %dateString and the time is %timeString"
I'm talking about building format strings just yet... I'm just
working with the suggestion that Walter brought up with
converting the interpolated string into something that can be fed
into format e.g.:
$"The date is {%04d year} and {user} just logged into {here}"
is rewritten by the compiler to:
"The date is %04d and %s just logged into %s", year, user, here
which can be fed into for example format(). Not sure I like the
need to call format to get the resulting string, but just working
with the idea here.
I also think it would loose a lot of value to only allow strings
as you suggest (e.g. %dateString).
Re: Interpolated strings
On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen
wrote:
What about supporting an optional prefix inside the {} like:
int year = 2017;
format($"The date is {%04d year}");
so if there is a % immediately following the { then the chars
until next whitespace is format specifier. You can of course
leave out the format specifier and it will default to %s.
I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `
As mentioned before it is only because it is such a common
pattern that it justifies the change. Seems like many other
languages reached that conclusion as well.
Also take a look at a more realistic example with some more
formatting and it will be more obvious (at least to me it is :) )
"The date is " ~ format("%04d", year)) ~ " and " ~ user ~ " just
logged into " ~ here;
$"The date is {%04d year} and {user} just logged into {here}"
Re: Interpolated strings
On Tuesday, 18 April 2017 at 08:42:38 UTC, Walter Bright wrote: On 4/15/2017 1:04 PM, Jonas Drewsen wrote: [...] Thanks for doing the work to make a sample implementation, too. I don't know if this will make it into D, but Jonas is a fine example of a champion. Thanks for the feedback. Nice to know that it is not immediately off the table at least :)
Re: Interpolated strings
On Wednesday, 19 April 2017 at 00:08:19 UTC, Walter Bright wrote:
On 4/18/2017 2:56 PM, Jonathan Marler wrote:
Have you thought about supporting format specifiers as well?
I looked at the C#
version and it looks like they can specify them using a colon
like this:
$"{a} in hex is {a:x}"
There are additional problems, such as:
$"{a} in %s {b}"
and positional parameters:
$"{a} in {0}"
Of course, the easiest solution is to just disallow that stuff.
What about supporting an optional prefix inside the {} like:
int year = 2017;
format($"The date is {%04d year}");
so if there is a % immediately following the { then the chars
until next whitespace is format specifier. You can of course
leave out the format specifier and it will default to %s.
Re: Interpolated strings
On Monday, 17 April 2017 at 19:12:37 UTC, Martin Tschierschke
wrote:
defining a new method exho! (derived from echo + mixin...:-)
auto exho(string x)(){
return mixin("writeln("~interp!x~")");}
You can just write:
exho!"The number ${num} doubled is ${num * 2}!"
It requires 'num' to be available to the exho function definition
so will not
work in the general case.
Re: Interpolated strings
On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
Hi all
I've been wanting to have support for interpolated strings in
D for some time now that will allow you to write e.g.:
auto a = 7;
writeln( $"{a} times 3 is {a*3}" );
Code speaks louder that words so I've made a PR that adds this
support to ddmd as a RFC [1].
The compiler will basically lower the $"..." string to a mixin
that concatenates
the expression parts of the (inside the {}) and the plain text
parts.
I do recognize that this is not part of the 2017 H1 plan but I
also believe such smaller improvements added regularly can make
the language both more productive and attractive.
In case this addition gets a thumbs up I will of course improve
test coverage and any needed quality of implementation.
[1] https://github.com/dlang/dmd/pull/6703
Seems like there are mixed opinions about inclusion of a thing
like this.
Looking at all the old PRs on dlang github slowly bit rotting it
makes me
wonder how not to end up in that pool.
I think that history has shown that Walter/Andrei are gatekeepers
on what
will ever get into the language. For the sake of contributers
(incl. me or course :) ) it would make sense to get a preliminary
"never going in" clarification by them early on. Even before a
DIP has been written because writing that takes a good amount of
effort.
Also collect these declined language change decisions (such as
AST Macros) on the wiki for future contributers to scan through
before anything else. I volunteer to add "interpolated strings"
to the page in case it gets declined. The page could also list
pre-approved language changes such as async functions (which
Walter wants afaik).
I guess the main question is really to Walter and Andrei if we
could get some kind "never going in" or "could be considered"
clarification on e.g. news group threads named like e.g.
"Language Design Change: Interpolated string"? Based on that the
next steps: DIP, PR etc. step would take place.
Re: Interpolated strings
On Sunday, 16 April 2017 at 00:25:19 UTC, Stanislav Blinov wrote: On Saturday, 15 April 2017 at 23:58:18 UTC, Adam D. Ruppe wrote: On Saturday, 15 April 2017 at 23:11:42 UTC, Stanislav Blinov wrote: How about... it removes an import or two? It doesn't actually remove the dependency, it is just syntax sugar over it (there is precedent for this in the language, the pow operator calls a Phobos function, but it means you don't actually gain decoupling of modules). As presented, it doesn't. But it can be implemented in a way that it does. The compiler is capable of conversions without ever needing std.conv, and if custom .toString() is required, it will already be available anyway. I guess the phobos dependency could be removed with some extra work which I'll happily do. But the main worry I hear from people is the added language complexity which isn't going away.
Re: Interpolated strings
On Sunday, 16 April 2017 at 08:01:02 UTC, Jacob Carlborg wrote: On 2017-04-15 22:04, Jonas Drewsen wrote: [...] My initial reaction is that this is something that can be implemented as library code if the language would have support for AST macros. On the other hand, this is something I would like to have in the language or the standard library. I'm in favor of AST macros but I think that has been shot down by Walter already afaik.
Re: Interpolated strings
On Saturday, 15 April 2017 at 21:03:27 UTC, Xinok wrote: On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote: Hi all I shared my thoughts on such a feature just a couple weeks ago: https://forum.dlang.org/post/oedeijdewmhazaqaz...@forum.dlang.org Most of you points applies to std.conv.text as well don't they? If you need special output buffers or memory management then use the tools right for that. This is about making the common case easier and keep the uncommon as it has always been.
Re: Interpolated strings
On Saturday, 15 April 2017 at 20:57:33 UTC, Jack Stouffer wrote: On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote: ... First, there's a process for language additions, please see https://github.com/dlang/DIPs/blob/master/README.md Secondly, I can tell you that any proposal that can be solved via the standard library has a very low chance of being accepted. D is already a complex language and it would take a important problem in order to justify making it more complex. As this is already do-able via Phobos, I would personally vote no to this addition. Thank you. I have been following the forums for many years so am aware of the process and chances of something like this getting in. For that exact reason I wanted to do a minimal implementation to show that I'm serious and a RFC. Doing a DIP is a lot of work that I'm only willing to use my time on if I have some confidence that it will not be in vain. I will do the DIP if this ever gets a thumbs up.
Re: Interpolated strings
On Saturday, 15 April 2017 at 20:35:56 UTC, crimaniak wrote:
On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
The compiler will basically lower the $"..." string to a mixin
that concatenates
the expression parts of the (inside the {}) and the plain text
parts.
It's easy implementable as a library (see
https://github.com/Abscissa/scriptlike#string-interpolation) so
it does not seem like a good idea to modify the language, only
to change interp!"" to $"".
Lowerings are by definition possible to implement in a library.
Using that argument foreach (i; 0..100) {} should not be part of
the
language even though I think very few would live without foreach.
Re: Interpolated strings
On Saturday, 15 April 2017 at 20:20:49 UTC, Stanislav Blinov
wrote:
On Saturday, 15 April 2017 at 20:12:41 UTC, cym13 wrote:
On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen
wrote:
This has been proposed before, and I still don't see the added
value compared to:
auto a=7;
writeln(a, " times 3 is ", a*3);
besides adding compiler complexity, language complexity and
parsing complexity which leaves room for more bugs to be
invented. I'm a bit more harsh than I could be, but if this
simple question has no clear answer I don't see why it sould
make it into the language.
Try a different context:
auto a = 7;
import std.format;
auto str = format("%s times 3 is %s", a, a*3);
//or
import std.conv;
auto str = text(a, " times 3 is ", a*3);
//or
auto str = $"{a} times 3 is {a*3}";
Yes this is a very basic lowering. The value comes from the fact
(assumption?) that this pattern of constructing a string from a
mix of strings and expressions is very common. The value of a
feature could be described as
usage * productivity_improvement = feature_value
So while the productivity_improvement may be modest the usage is
high enough to give a high feature_value and justify the
addition. A sign of this is the number of other popular languages
supporting this feature (not arguing for just copy other
languages but it is still an indicator). Unfortunately I have no
hard data for these numbers.
Interpolated strings
Hi all
I've been wanting to have support for interpolated strings in D
for some time now that will allow you to write e.g.:
auto a = 7;
writeln( $"{a} times 3 is {a*3}" );
Code speaks louder that words so I've made a PR that adds this
support to ddmd as a RFC [1].
The compiler will basically lower the $"..." string to a mixin
that concatenates
the expression parts of the (inside the {}) and the plain text
parts.
I do recognize that this is not part of the 2017 H1 plan but I
also believe such smaller improvements added regularly can make
the language both more productive and attractive.
In case this addition gets a thumbs up I will of course improve
test coverage and any needed quality of implementation.
[1] https://github.com/dlang/dmd/pull/6703
Foundation donations
Hey I've made a donation to the foundation. My employer has a matching program but the info about the foundation is lacking a bit on the dlang.org site. Specifically I miss: Mailing address Phone number Also the foundation page doesn't specify that it is a 501(C)(3) org. (notice the number 3) which in my case is important. Can you provide this info please? Thanks /Jonas
Re: Gui in D: I miss this project
On Wednesday, 11 January 2017 at 09:17:45 UTC, aberba wrote: On Wednesday, 11 January 2017 at 07:21:22 UTC, thedeemon wrote: On Monday, 9 January 2017 at 21:41:37 UTC, aberba wrote: [...] No drag, DLangUI is quite fine and usable (and already being used in industry). Or are you talking about including it into Phobos? That's not the best idea, it would make Phobos unnecessary fat and involve some dependencies complicating things, besides there is never a consensus regarding a GUI library, trying to include any GUI library is a recipe for eternal flamewar about all the different aspects of what GUI library should be and do. If you need some GUI, DLangUI is just a "dub build" away. I'm worried about it not becoming abandoned. This. Dlangui does seem too fat to add to phobos. What could be done in general for these cases is to let the D org. pick a couple of important libraries that is not suited for Phobos and try to move them to the dlang github org as owner (if current owner agrees of course). Original owner becomes lead/driver on the moved repo. That would be strong sign of commitment and in case of the original owner losing interest the dlang org. can assign a new driver.
Re: The end of curl (in phobos)
On Friday, 6 May 2016 at 13:25:55 UTC, Adam D. Ruppe wrote: On Friday, 6 May 2016 at 13:12:31 UTC, Jonathan M Davis wrote: [...] I have an HTTP client lib, I'm pretty sure Vladimir does too, and I think vibe wrote one for their framework. I'm sure we're not the only ones. I also have an XML lib, and again, I'm pretty sure Vladimir does too... [...] But std.net.curl supports not just HTTP but also FTP etc. so i guess that won't suffice.
Re: State of interfacing with c++
On Friday, 18 March 2016 at 20:50:59 UTC, Walter Bright wrote: On 3/18/2016 6:45 AM, Jonas Drewsen wrote: [...] dmd itself is a D main program that calls a lot of C++ code (the optimizer and back end) and so interfacing to C++ works on every platform dmd runs on. My concern was mostly if I could use visual c++ compiled backed to link with dmd/ldc/gdc compiled modules or if the c++ part must to be compiled a non-vc compiler e.g. dmc, gcc, clang to work. Because making our existing app compile on e.g. windows using something else that visual c++ would definitely increase the work load.
State of interfacing with c++
For a hack week at work I am thinking about creating a module in D that can be used with our existing application which is written in C++. Can anyone shed some light on the current status of interfacing with C++? In particular: 1, Can I build my C++ program using visual c++ and then link a D module compiled with gdc/ldc/dmd into it using the ms linker? 2, Can I do the same with the OSX tool chain ie. compile main program using xcode clang etc. 3, And what about linux? 3, Which features of D or C++ should I expect not to work or shouldn't use when interfacing. Any pointers to reasonably up-to-date info about interfacing with c++ is much appreciated as well. Thanks
I guess this is good GSOC 2016 news?
https://summerofcode.withgoogle.com/organizations/?sp-category=languages
Re: Hotfix release vibe.d 0.7.28
On Monday, 29 February 2016 at 07:54:09 UTC, Sönke Ludwig wrote: Now I'm leaning towards finalizing the new prototype library and proposing it for Phobos inclusion at some point. Would that library support the same event sources as libasync ie. filesystem, notification, sockets etc? I really think this kind of thing is missing in phobos atm. no matter if it is a new lib from you or libasync+optimizations.
Re: Wishlist for D
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
Hi
We all have experience with several programming languages and
the great ideas implemented there. It is close to Xmas
The one wish I have is to be able to call stuff directly without
needing to import the module (like you can in c#):
std.stdio.writeln("foo")
and not
import std.stdio;
writeln("foo");
Simple thing - but used regularly enough to be quite annoying not
to have.
I wonder if there are some kind of parsing/semantic issues with
supporting it?
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Sunday, 1 November 2015 at 02:41:37 UTC, Andrei Alexandrescu wrote: On 10/31/15 5:24 PM, Jonas Drewsen wrote: [...] Many thanks to both you and ponce! This is great work. I have good news and bad news. The bad news is we won't likely be able to accept either of these proposals. [...] No worries - I just quickly threw something together that I though could do. Having an actual pro team behind this is great news!
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Sunday, 25 October 2015 at 23:59:16 UTC, Andrei Alexandrescu wrote: On 10/25/15 8:04 AM, ponce wrote: On Friday, 23 October 2015 at 16:37:20 UTC, Andrei Alexandrescu wrote: http://dconf.org/2016/index.html Do you need a new logo this year? I would be happy to make another, better one. Yes please! Forgot to mention that. Many thanks!! -- Andrei I gave it a shot: https://dl.dropboxusercontent.com/u/188292/g4421.png /Jonas
Re: GuiDub
On Tuesday, 29 September 2015 at 07:47:31 UTC, Sönke Ludwig wrote: It is usable as a library! The API still needs a review pass before it can be declared stable for 1.0.0, though, because it wasn't initially considered as an external API and is still lacking in some areas, such as documentation. Now that is awesome! I've had to implement parsing, paths resolving etc. for dub.json myself so far and have always wished there was a library.
Re: Is Anything Holding you back?
On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote: You can easily make attributes effectively available at runtime by building lists of attributed things at compile time. I don't understand your problem. Describe the goal? This is all nice but still not as slick as could be. Say a want to have a central place to lookup all classes with the Foo() attribute on it. The classes can be in several files of course so there are two ways of registering them at compile time to be available for runtime lookups: 1, Add a static module contructor to each module that registers the Foo() attribut'ed classes. This constructor is probably generated at compile time and mixed into the module as a one-liner. 2, Add a "registration" module that imports all other modules in order to filter out Foo() attributed classes and register them for runtime usage. The first method is bad because you need to mixin code manually for each module you have. The second method is bad because you need to keep the "registration" file in sync with any modules added/renamed/removed. A couple of months ago I was working on an extension to the string import() feature of D: It would simply treat a import(*) as returning the directory listing of the imports path. From that the list of .d file could be figured out and imported at compile time. Then the the runtime information could be extracted at compile time with no fuzz. /Jonas
Re: Is Anything Holding you back?
On Monday, 5 October 2015 at 13:38:43 UTC, Adam D. Ruppe wrote: On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote: Say a want to have a central place to lookup all classes with the Foo() attribute on it. You can also use the RTInfo hook in druntime's object.d to build that stuff in a central location. Of course, since that's a centralized file, it can at best be changed on a per-project basis... And it wouldn't work if you want to put your app on e.g. code.dlang.org for others to compile using their standard druntime. Furthermore RTInfo seems kind of reserved for GC atm. There's also only RTInfo for types, not functions and variables, but still, it'd work for the case of building a list of classes. Types goes a long way for sure. Personally I need both types and functions.
Re: Experience: Developing Cloud Foundry applications with D
On Monday, 5 October 2015 at 06:24:44 UTC, Andrei Alexandrescu wrote: On 10/5/15 1:34 AM, Rikki Cattermole wrote: Vibe.d has a provider called libasync. Libasync is fully implemented in D. You probably should have tried that at least. Although I still would recommend trying it ;) It's a lot better then what we have in Phobos. Cue choir asking for porting of libasync to phobos. I've first asked this a couple of years ago. -- Andrei
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Congratulations!
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 20:29:15 UTC, Jonas Drewsen wrote:
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done
anything interesting with them?
I use a few in the deadcode editor e.g.:
Function can be called by a menu entry:
@MenuItem(Edit/Copy)
Function can be called by a shortcut:
@Shortcut(shift + f10)
Function should run in a fiber when called:
@InFiber
Just remembered, I also use it for the animation system to tell
what can be animated (modified by proxy) e.g:
@Bindable()
{
CSSPositionMix _position;
CSSScaleMix _width;
CSSScaleMix _height;
CSSVisibility _visibility;
...
}
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? I use a few in the deadcode editor e.g.: Function can be called by a menu entry: @MenuItem(Edit/Copy) Function can be called by a shortcut: @Shortcut(shift + f10) Function should run in a fiber when called: @InFiber
Re: Why aren't you using D at work?
On Wednesday, 3 June 2015 at 04:53:05 UTC, ketmar wrote: On Wed, 03 Jun 2015 03:27:35 +, weaselcat wrote: On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis wrote: On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote: so is std.xml the exception? How many other parts of the standard library are like that? A few, but not many. Mostly, it's stuff that was done for D1 or very early D2 which hasn't been removed or replaced yet. std.xml, std.json, and std.stream are what come to mind. There may be a few others, but most of the stuff in Phobos is more recent and is properly maintained. Mostly, it's a question of what hasn't been added to the standard library yet rather than what needs to be replaced. - Jonathan M Davis std.signals and there is an excellect replacement[1]! [1] https://github.com/phobos-x/phobosx/blob/master/source/phobosx/ signal.d Nice! just what I've been looking for. I hope it works as expected.
Re: Working on new binary serialization module for phobos (hopefully)
On Monday, 1 June 2015 at 19:41:58 UTC, Jacob Carlborg wrote: On 2015-06-01 21:22, CraigDillabaugh wrote: I noticed there hasn't been any activity on the Github repo for 8 months. Why is that? Do you consider this a completely finished product, or are you held up by the PHobos review process? I just haven't worked on it for a while. Working on the , at least, third review process isn't really motivating. Couldn't be put into std.experimental. That would probably be both motivating and increase testing of the API. /Jonas
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On Friday, 29 May 2015 at 23:42:00 UTC, Andrei Alexandrescu wrote: DConf 2015 has been awesome, I'm taking a minute to post this that's been announced a short while ago. We're pleased to announce that DConf 2016 will take place in Berlin, sponsored by Sociomantic. Good news indeed! Thanks to Sociomantic for doing this.
Re: Which D IDE do you use?(survey)
Using Deadcode, emacs, VisualStudio, sublime. Please post results. I'm probably the only one using Deadcode for now though :) Anyway, for me the more important question is what features of your IDE/editor makes you stick with it or makes it the best one for you? And finally what features you haven't seen anywhere else that you put in your own editor if you had the time to do that? /Jonas
Re: Questions about phobos additions mentioned in 2015H1 vision document
3. When mentioning networking, do you mean email handling, http servers, sockets etc? Do you see this replacing std.net.curl? All of the above. Some may build on curl, some may complement it, some may replace some of its functionality. I would like to see e.g. libasync mature a bit and get into std.async. From there http, ftp... client and server could be added to std.net if we want to. I am currently using libasync in Deadcode with great success. https://github.com/etcimon/libasync /Jonas
Re: Deadcode on github
On Thursday, 26 March 2015 at 00:26:58 UTC, Dicebot wrote: On Tuesday, 17 March 2015 at 12:39:00 UTC, Jonas Drewsen wrote: Definitely. I've now made a branch linux on github where linux compiles and links successfully and that also includes steps towards abstracting stuff. Thanks a lot. Sadly this branch still doesn't seem to compile because of other issues (that don't seem to be related to platform portability). I think I will wait for some tagged release before rushing into experiments :) I fully understand. After the next release my focus will be on porting to mac and linux. /Jonas
Re: Deadcode on github
On Tuesday, 17 March 2015 at 11:08:07 UTC, Dicebot wrote: On Monday, 16 March 2015 at 20:17:05 UTC, Jonas Drewsen wrote: On Monday, 16 March 2015 at 18:27:52 UTC, Dicebot wrote: On Monday, 16 March 2015 at 15:14:03 UTC, Jonas Drewsen wrote: Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. I got bunch of errors from windowdragger.d amd guiapplication.d modules because those directly import windows api stuff and use types like `DWORD` and friends. I see :( The windowdragger.d could be fixed on linux using something from : http://rosettacode.org/wiki/Mouse_position#C The guiapplication.d is stuff for watching dirs, locating window position info, and getting default dir paths e.g. user dir. Hiding platform-specific details behind a more abstract API wrapper would make adding linux support much easier ;) Definitely. I've now made a branch linux on github where linux compiles and links successfully and that also includes steps towards abstracting stuff.
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 17 March 2015 at 08:34:13 UTC, Sönke Ludwig wrote: Am 16.03.2015 um 22:38 schrieb Martin Nowak: Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin Corresponding vibe.d release cadidate (0.7.23-rc.1) is now up for testing as well: http://code.dlang.org/packages/vibe-d I see that vibe-d dependencies lists libevent 2.0.x or libev. Any plans to add libasync as a third option?
Re: Deadcode on github
On Monday, 16 March 2015 at 18:27:52 UTC, Dicebot wrote: On Monday, 16 March 2015 at 15:14:03 UTC, Jonas Drewsen wrote: Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. I got bunch of errors from windowdragger.d amd guiapplication.d modules because those directly import windows api stuff and use types like `DWORD` and friends. I see :( The windowdragger.d could be fixed on linux using something from : http://rosettacode.org/wiki/Mouse_position#C The guiapplication.d is stuff for watching dirs, locating window position info, and getting default dir paths e.g. user dir.
Re: Deadcode on github
On Monday, 16 March 2015 at 10:07:16 UTC, Dicebot wrote: On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode GitHub README.md is a natural place for such information. How far you estimate it from being buildable/usable on Linux? It was buildable on Linux a month ago on my server. Usable I cannot say because I have never tried it on a linux box with a monitor. It really hurts me to say since I've been a die hard linux user for many years, but my work the recent years has been solely mac/win which led me in this direction. That will change at some point though. Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. /Jonas
Re: Deadcode on github
On Monday, 16 March 2015 at 15:37:00 UTC, ketmar wrote: On Mon, 16 Mar 2015 15:14:02 +, Jonas Drewsen wrote: Meanwhile I'm happy to assist anyone willing to give a shot on building it on linux. It is currently based on SDL so with bit of luck it is not that hard. i tried to build it, but no luck: it can't build libdparse. ah, the joy of dub... is there any way to build some testing app that doesn't require libdparse? i'm not in a mood of fixing anything right now... It is only extensions that using libdparse. You should be able to remove extensions/language/d folder and the extensions/highlight/d.d file and make it work I believe.
Re: Deadcode on github
On Monday, 16 March 2015 at 09:52:55 UTC, extrawurst wrote: On Sunday, 15 March 2015 at 22:33:34 UTC, Jonas Drewsen wrote: On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: On 3/15/2015 2:39 PM, Jonas Drewsen wrote: Here you go... Website: http://deadcode.steamwinter.com Changelog: http://deadcode.steamwinter.com/downloads/Changelog.txt Trello:https://trello.com/b/ufLqwxVW Thank you! BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode I know... and you are right. On the todo... just soo much more fun to code D than HTML. Then use vibe.d and code it in D :D As a matter of fact I am using vibe.d for the website. Unfortunately I found out that the iteration time is quite bad which is important for web development. It would especially be nice if vibe.d could detect if there is no D logic in the diet file and if not parse+render it directly at runtime instead (may in dev mode only). That way you would not have to wait for compile+link everytime you insert a paragraph you want to preview. /Jonas
Re: Deadcode: A code editor in D
On Friday, 13 March 2015 at 16:33:38 UTC, Kingsley wrote: Up to your imagination! Personally I will probably use them to integrate 3rd party tools or create small helpers in my day to day work that are currently small bash/bat scripts. Using D for scripting this way would be very nice imho. Of course the editor itself can (and does) make use of such widgets to show misc. info about you project state. /Jonas Could you put the code on github or somewhere so I can have play with it? I don't care what state the code is in or if stuff fully works or not - just want to have a go. I'm writing an intellij plugin for D https://github.com/kingsleyh/DLanguage and curious to see other approaches to editing D code. --K FYI: http://forum.dlang.org/post/hbnjepeljfdlnaagn...@forum.dlang.org
Deadcode on github
Hi Some people have shown interest in getting access to the source code of the Deadcode editor. I haven't done this earlier because of lots of dirty bits I wanted to clean up first. But I figured that it was better to get early feedback on dirty code than too late feedback on shiny code. I have also opened access to the WIP website and the Trello board I use. In case anyone ends up contributing just ask for Trello edit access. Here you go... Website: http://deadcode.steamwinter.com Changelog: http://deadcode.steamwinter.com/downloads/Changelog.txt Trello:https://trello.com/b/ufLqwxVW There are binaries for windows on the website but I have not verified them working on something other than the same machine I work on. So cannot tell if it work as expected - please tell about any issues. I'll work on improving first time experience but let me known what you think. /Jonas TL;DR; I currently use Deadcode when coding Deadcode itself except for debugging. I have not used it for other projects yet so you may find issues there. Keybindings are a mostly emacs like but with some other standard included like ctrl+c/v copy/paste etc. The keybindings file can be changed to fit your needs if you don't like emacs style. Useful shortcuts to know: ctrl + m will show build panel ctrl + p will show command buffer listing commands ctrl + , will let you select current dub project files ctrl + n new extension/file f7 build dub project and show issues panel f8 frame next build issue in panel and open file on line Lots of other goodies I need to put in the docs soon. You move the window on the menu button only (maybe I'll change that later - dunno) Mac and linux build are on the roadmap. You might need to boostrap your keybindings file to make it interesting. Haven't got around to automate this yet. copy the file below to C:\Users\your-login\AppData\Roaming\DeadCode\ http://deadcode.steamwinter.com/downloads/key-mappings-emacs
Re: Deadcode on github
On Sunday, 15 March 2015 at 22:07:04 UTC, Walter Bright wrote: On 3/15/2015 2:39 PM, Jonas Drewsen wrote: Here you go... Website: http://deadcode.steamwinter.com Changelog: http://deadcode.steamwinter.com/downloads/Changelog.txt Trello:https://trello.com/b/ufLqwxVW Thank you! BTW, you need to prominently place a couple paragraphs describing: what Deadcode is why someone should be interested in Deadcode I know... and you are right. On the todo... just soo much more fun to code D than HTML.
Re: Deadcode: A code editor in D
On Friday, 13 March 2015 at 16:33:38 UTC, Kingsley wrote: Up to your imagination! Personally I will probably use them to integrate 3rd party tools or create small helpers in my day to day work that are currently small bash/bat scripts. Using D for scripting this way would be very nice imho. Of course the editor itself can (and does) make use of such widgets to show misc. info about you project state. /Jonas Could you put the code on github or somewhere so I can have play with it? I don't care what state the code is in or if stuff fully works or not - just want to have a go. I'm writing an intellij plugin for D https://github.com/kingsleyh/DLanguage and curious to see other approaches to editing D code. I will see if I can find some time this weekend to put it on github. /Jonas
Re: Deadcode: A code editor in D
On Sunday, 8 March 2015 at 20:33:44 UTC, Kingsley wrote: On Monday, 19 January 2015 at 20:41:11 UTC, Rikki Cattermole wrote: On 20/01/2015 1:48 a.m., Jonas Drewsen wrote: On Sunday, 18 January 2015 at 22:00:51 UTC, Piotrek wrote: On Friday, 16 January 2015 at 21:19:08 UTC, Jonas Drewsen wrote: I have been working on an editor written in D for use with D for some time now and have made a blog post about it. Any feedback or suggestions are welcome. http://deadcodedev.steamwinter.com Thanks Jonas Hi, This is an impressive work. I's really nice to see a presentation of how much help can be provided from the D editor and existing language labiaries. I have several questions as well: 1. Was the libdparser integrated with extension system or is it embedded in the core? Done with the extension system. 2. What are the dependencies? sdl2, opengl, freetype, libdparse (if you want the extension for D semantic) I am keeping an eye on some of the native D input/window libraries that is being worked on in the hope of being able to replace the SDL2 dependency. Please file any enhancement requests for any Devisualization projects you need. It would help me know what is needed of them more. 3. How hard it would be to change the feellook of the gui as it is in conventional editors (Visual, MonoDeveop, GtCreator, Eclipse). I mean menus, buttons, views etc? Would require some more views/controls to be created. The styling is done through CSS sheets. A common subset of CSS keys are supported but maybe a few more would be needed. What is the purpose of the widgets in deadcode Up to your imagination! Personally I will probably use them to integrate 3rd party tools or create small helpers in my day to day work that are currently small bash/bat scripts. Using D for scripting this way would be very nice imho. Of course the editor itself can (and does) make use of such widgets to show misc. info about you project state. /Jonas
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 23:45:36 UTC, ketmar wrote: On Tue, 03 Mar 2015 20:21:29 +, Jonas Drewsen wrote: I've done a GUI toolkit with CSS support in D for my editor. Should probably put it on github at some point. http://deadcodedev.steamwinter.com/ to be honest, it's the most wanted part for me. ;-) i don't need the editor, but i definitely want to take a look at it's gui, 'cause i'm too lazy to finish any of my own libraries (i HATE writing gui libraries! ;-). Yeah. Driving people away from the editor they know is a tough quest. Luckily that is not my goal. Writing GUI libraries is definitely a lot of work and have a lot of corner cases so I completely agree that it is not the most fun thing to do. On top of that it is hard to do proper automated tests for GUI.
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: Hi all ... However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings. I've done a GUI toolkit with CSS support in D for my editor. Should probably put it on github at some point. http://deadcodedev.steamwinter.com/ No QML-like thing because I feel that belongs in code. For now anyway. /Jonas
Re: Unreal Bindings
On Tuesday, 3 March 2015 at 17:15:47 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 3 March 2015 at 15:59:20 UTC, Per Nordlöw wrote: Unreal Engine 4 is not free: https://www.unrealengine.com/blog/ue4-is-free D bindings anyone? Yes, please! Although 5% of gross earnings is more like «free»... Shameless plug. Unity3d 5.0 is now free and with no revenue share. http://unity3d.com
Re: Unreal Bindings
On Tuesday, 3 March 2015 at 22:07:43 UTC, Kiith-Sa wrote: On Tuesday, 3 March 2015 at 22:01:46 UTC, Jonas Drewsen wrote: On Tuesday, 3 March 2015 at 17:15:47 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 3 March 2015 at 15:59:20 UTC, Per Nordlöw wrote: Unreal Engine 4 is not free: https://www.unrealengine.com/blog/ue4-is-free D bindings anyone? Yes, please! Although 5% of gross earnings is more like «free»... Shameless plug. Unity3d 5.0 is now free and with no revenue share. http://unity3d.com aaand no source code access, i.e. no ability to work on D bindings (or, of fixing bugs when they can't be fixed in a timely fashion - after all, prioritized bug handling (still not nearly as good as source access) comes at a cost). If you want to use D with Unity I guess you could just use the native api http://docs.unity3d.com/Manual/NativePlugins.html I haven't tried myself yet but could be fun to do.
Re: Refactoring D as an MSc Project
On Monday, 2 March 2015 at 21:50:46 UTC, Jamie wrote: Hello all! This is my first post on the forums. I'm interested in possibly creating a refactoring tool for D for my MSc dissertation (I notice there is currently no refactoring in D?). I wanted to ask if this is possible with D's current state? More specifically: - Can I easily access things such as the AST? I have planned to do refactoring tools myself for D for use in Deadcode (an editor). I'm currently using libdparse myself for other things, but the overview given for SDC last dconf looked very promising. I would be very interested in following what you do and be an early adopter if possible. /Jonas
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 22:16:36 UTC, Freddy wrote: On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: Hi all I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented. In that duscussion many participants agreed that Qt would be a good foundation, but had very restrictive license. Things have changed since then, and Qt now is available under LGPL, which, to my undestanding, makes it suitable for the purpose of standard GUI library (please correct me if I am wrong on this). The license, of course, may change in the future, preventing us from using their updates for our drawing engine. But if we are able to start using the engine now, in the future we can maintain the updates ourselves. Now, how I envision the library's design: The library will be mostly implemented in D, except for drawing engine and event loop, which are system-dependent. Those two parts will be extracted from Qt into a separate library which will be linked to by the rest of framework either statically or dynamically. There will be bindings for sending drawing instructions to drawing engine, as well as for retrieving system and GUI events from event loop. The system-independent part will mimic architecture of Qt. However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings. If there is no standard GUI for D yet, and if LGPL license fits our purpose, then I am looking for 2-3 Qt experts to join me and build the framework. Thanks, Aram I'm not much of a gui person,but what is the advantage of using QML over D's import statements(http://dlang.org/expression.html#ImportExpression) and CTFE. No need to recompile (ie. have the source code) the app you are doing when you change the QML. This in turn also speeds up design iterations.
Re: Deadcode - Widgets and Styling post
On Monday, 9 February 2015 at 22:36:45 UTC, David Ellsworth wrote: On Monday, 9 February 2015 at 21:08:18 UTC, Brad Anderson wrote: I've never seen anyone post under the name deadcode on the forums so don't think there is much potential for confusion (especially since one is a project and another is a person). I think you should keep the name. Well, even if I do start posting here more frequently, I think I'll still be okay with this. As you said one is a project and the other is a person! I don't think anybody here will be confused. :) Cool. If you are ok with it then I'll stick with the name. Thx. Jonas
Re: Deadcode - Widgets and Styling post
On Tuesday, 10 February 2015 at 06:42:45 UTC, Phil wrote: This looks great. Do you have any idea roughly when an alpha release will be available? Some months I would guess. On Monday, 9 February 2015 at 22:36:45 UTC, David Ellsworth wrote: On Monday, 9 February 2015 at 21:08:18 UTC, Brad Anderson wrote: I've never seen anyone post under the name deadcode on the forums so don't think there is much potential for confusion (especially since one is a project and another is a person). I think you should keep the name. Well, even if I do start posting here more frequently, I think I'll still be okay with this. As you said one is a project and the other is a person! I don't think anybody here will be confused. :)
Re: Deadcode - Widgets and Styling post
On Monday, 9 February 2015 at 21:08:18 UTC, Brad Anderson wrote: On Monday, 9 February 2015 at 20:33:46 UTC, Jonas Drewsen wrote: I made a short post about extending Deadcode (D editor) with a custom widget and how to style it using CSS. http://deadcodedev.steamwinter.com/ Enjoy /Jonas PS. I'm still wondering what to do about the name clash with one of the nick names on this forum ie. deadcode. Very cool stuff. Is the majority of that time it takes to compile, the state serialization/deserialization or is dmd being that slow? Compilation time mostly, but it is compiling everything from scratch every time in this video. I have already factored it out into a backend lib and a frontend in order to speed up compilation, but I cannot remember if that actually speeds up anything. Will have to check. Serialization time is not noticable. It would be really neat to integrate with neovim so we vim users could get our beloved keybindings. Neovim has enabling integration with editors as one of its design goals though I'm not sure how far along they are on this front. Last I heard it was supposed to be over a messagepack API. Haven't heard of it before. Will definitely check it out. I'm used to emacs keybindings myself. It'd be cool if you went over how you've implemented all of this a bit. The architecture seems very interesting. Seems like a good topic yes. Will put it on the list. A higher resolution recording would be nice. Some of the characters get lost at this resolution. yes, I see that the youtube quality is quite bad. The uploaded version was perfectly fine so I wonder what went wrong. I've never seen anyone post under the name deadcode on the forums so don't think there is much potential for confusion (especially since one is a project and another is a person). I think you should keep the name. I have grown a bit attached to the name now working on it for quite a while I must admit.
Deadcode - Widgets and Styling post
I made a short post about extending Deadcode (D editor) with a custom widget and how to style it using CSS. http://deadcodedev.steamwinter.com/ Enjoy /Jonas PS. I'm still wondering what to do about the name clash with one of the nick names on this forum ie. deadcode.
Re: New menus are up
On Tuesday, 20 January 2015 at 03:33:19 UTC, Andrei Alexandrescu wrote: ... aand we already have a contender! https://github.com/D-Programming-Language/dlang.org/pull/790 Looks better than dlang.org? Yeah definitely... better colors and spacing.
Re: Deadcode: A code editor in D
On Sunday, 18 January 2015 at 22:00:51 UTC, Piotrek wrote: On Friday, 16 January 2015 at 21:19:08 UTC, Jonas Drewsen wrote: I have been working on an editor written in D for use with D for some time now and have made a blog post about it. Any feedback or suggestions are welcome. http://deadcodedev.steamwinter.com Thanks Jonas Hi, This is an impressive work. I's really nice to see a presentation of how much help can be provided from the D editor and existing language labiaries. I have several questions as well: 1. Was the libdparser integrated with extension system or is it embedded in the core? Done with the extension system. 2. What are the dependencies? sdl2, opengl, freetype, libdparse (if you want the extension for D semantic) I am keeping an eye on some of the native D input/window libraries that is being worked on in the hope of being able to replace the SDL2 dependency. 3. How hard it would be to change the feellook of the gui as it is in conventional editors (Visual, MonoDeveop, GtCreator, Eclipse). I mean menus, buttons, views etc? Would require some more views/controls to be created. The styling is done through CSS sheets. A common subset of CSS keys are supported but maybe a few more would be needed.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:43:05 UTC, MattCoder wrote: On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. Well I'd prefer less red-ish: http://i.imgur.com/AIvcoWl.png But you know this is a personal thing, and if you looking for martian aspect so you're ok. Anyway this menu is better than your previous one. :) Matheus. Much better with using gray as the base color. But I think a red tone matching something in the logo should be used instead of the orange color for the selected item. Otherwise it will look inconsistent. Also... Shouldn't we get rid of the brown/red gradient in the background? /Jonas
Re: Deadcode: A code editor in D
On Saturday, 17 January 2015 at 13:32:37 UTC, MattCoder wrote: On Saturday, 17 January 2015 at 06:14:12 UTC, Jonas Drewsen wrote: Do you have some info/link to your editor? I'm currently writing in D using GtkD (http://code.dlang.org/packages/gtk-d), and using Cairo to manage the text drawing. It you have thoses dependencies already then why not use gtksourceview for the editor stuff? It took me quite some time to do that ie. undo/redo system, text layout, highlight system, navigation, text anchors, efficient text and line gapbuffers etc. You get that for free with gtksourceview. It will not have a menu, just a console at bottom. I'm wanting it to be simple with some features that I like most and the keybindings that fit in my Dvorak layout better. The Menu button will be different in the final version and maybe hidden by default. I am used to emacs keybindings myself but have designed it around being able to use either emacs, vi or standard bindings. I'll release it at some point, but I want to polish more before that. :) I known the feeling :)
Re: Deadcode: A code editor in D
On Friday, 16 January 2015 at 21:25:09 UTC, ketmar via Digitalmars-d-announce wrote: On Fri, 16 Jan 2015 21:19:06 + Jonas Drewsen via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I have been working on an editor written in D for use with D for some time now and have made a blog post about it. Any feedback or suggestions are welcome. is it working in GNU/Linux? and will the source code be available? It is currently only compiling on linux and I haven't tried to start it there. It is based on libsdl so I don't see much trouble in getting it to work. Funny because linux used to be my only OS for many years until I got my current job where we don't use linux in general. I'll probably open source it when it is out of beta. /Jonas
Re: Deadcode: A code editor in D
On Friday, 16 January 2015 at 21:23:49 UTC, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 21:19:08 UTC, Jonas Drewsen wrote: I have been working on an editor written in D for use with D for some time now and have made a blog post about it. Any feedback or suggestions are welcome. http://deadcodedev.steamwinter.com A completely unhumble request: Please change the name :) Deadcode is the Internet nickname of my good friend David Ellsworth, who is also a D programmer, and with whom I have attended DConf 2013 and 2014. As there is already a Deadcode in D, a second one is a name collision :) I'll give it a thought.
Re: Deadcode: A code editor in D
On Friday, 16 January 2015 at 21:41:39 UTC, ketmar via Digitalmars-d-announce wrote: On Fri, 16 Jan 2015 21:32:32 + Jonas Drewsen via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: It is currently only compiling on linux and I haven't tried to start it there. It is based on libsdl so I don't see much trouble in getting it to work. so it's using it's own ttf renderer (or SDL_ttf)? ah, too bad for me. :-( It is using SDL_ttf to render glyphs to fontmaps. I use these together with opengl in the text layout engine to get the final result. I'll probably open source it when it is out of beta. may i ask why don't you go with open source from the start? i'm not insisting on anything, i'm just curious. It started out on my own github server with a lot of expermentation that didn't make sense to share and it just wasn't a priority to open source it before it was ready.
Re: DConf 2015 Call for Submissions is now open
On Thursday, 8 January 2015 at 10:31:58 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 6 January 2015 at 23:24, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Hello, Exciting times! DConf 2015 will take place May 27-29 2015 at Utah Valley University in Orem, UT. Awesome, that runs over my birthday (28th). My friends and family won't be too pleased. :-) Iain Hey that is my birthday as well :) Same deal.
Re: Tharsis.prof 0.1: a frame-based profiler for game development
On Friday, 5 September 2014 at 11:06:56 UTC, Kiith-Sa wrote: Announcing Tharsis.prof, a frame-based profiler in D. Awesome. Looking forward to check it out! /Jonas
Re: [OT] DConf - How to survive without a car?
On Thursday, 8 May 2014 at 14:34:13 UTC, Steven Schveighoffer wrote: On Wed, 07 May 2014 00:11:45 -0400, Mike n...@none.com wrote: On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote: Hi all, After last year's incident with my tires getting slashed, I'm really hoping I can do without a car during this year's DConf. How feasible is this? I'll be staying at Aloft. Would be great if there's someone I can share a ride with. I've also seen there's a public bus going more or less to FB and back, so I should be good there. (Right?) But how about getting to SFO or down town? Am I causing myself a whole lot of pain (albeit of a different kind) by not renting a car? To be clear, I'm not looking for an economical option, just peace of mind. Lio. I'm wondering about this myself. My current plan to get from SFO to the Aloft is via BART (SFO - Balboa Park - Bay Fair - Freemont) and then take a bus or a taxi from Freemont to the hotel. Just FYI, I took BART and buses to my hotel last year, it took 2.5 hours. When Andrew drove me back to the airport from facebook, it took 30 minutes. Something to think about :) Also, the site 511.org is awesome for using public transportation in the bay area. But, thinking about it a little more, a car is starting to look pretty good. I will have a car this year, and will play taxi driver from Aloft to facebook. Excellent. I need a lift if possible? Of so please tell me when I should be in the aloft lobby? /Jonas
Re: Progress on Adam Wilson's Graphics API?
Just had a quick look at the source code. If this is to be something like the official gfx library wouldn't it make sense to follow the phobos coding style? For example struct Size instead of struct SIZE /Jonas
Re: Emacs users: flycheck-dmd-dub
On Thursday, 20 March 2014 at 07:17:04 UTC, Sönke Ludwig wrote: Am 19.03.2014 00:16, schrieb Atila Neves: V0.0.4 now supports both package.json and dub.json Atila There is one change that I would highly recommend - using the output of dub describe instead of directly reading dub.json: - It's planned to add an SDL based format, which otherwise then would also have to be supported I currently have a tool that read and writes the dub.json files. What would you suggest for this tool since describe would only solve the reading part and not the writing. Furthermore adding SDL format as well doubles the effort for this. Is dub usable as a library so that this wouldn't be a problem? /Jonas
Re: ddox-generated Phobos documentation is available for review
Very nice! std.algorithm, std.net.curl etc. have their functions/classes split in categories. I haven't used ddox myself but would it be possible to modify it to read a category variable in the documentation for a function and then use that to group things in the resulting html file? Or would that need modifications to dmd itself. /Jonas
Re: DDOX search support and new 2.064.2 Phobos docs
Very nice! Looking at the automatic index created for a module I guess it is using the first line of the function comment as the description column right? If that is the case we should probably go through phobos and make proper first lines that works as summeries. /Jonas
Re: Lexers (again)
On Friday, 13 December 2013 at 10:17:49 UTC, Brian Schott wrote:
I've been working on the next attepmpt at a std.lexer /
std.d.lexer recently. You can follow the progress on Github
here: https://github.com/Hackerpilot/lexer-work
knit picking... but shouldn't:
size_t line() pure nothrow const @property { return _line; }
be more like:
@property size_t line() pure nothrow const { return _line; }
to be consistent with phobos coding style?
/Jonas
Re: Should std.net.curl be moved from Phobos to Deimos?
On Thursday, 28 November 2013 at 16:24:34 UTC, Adam D. Ruppe wrote: On Thursday, 28 November 2013 at 11:37:45 UTC, Jonas Drewsen wrote: I definitely agree. In addition D has obtained some nice features since the definition of the std.net.curl API that I would liked have used back then. What are you thinking of there? I think plain old classes and delegates are a good fit for http stuff. Indeed, the basic design for wrapping curl is not that bad I think. One thing that was not available was UFCS which I think could have made the API look a bit different. Another thing that could have have affected the API is support for named parameters which is still not supported (and probably never will?). /Jonas
Re: Should std.net.curl be moved from Phobos to Deimos?
On Wednesday, 27 November 2013 at 01:32:18 UTC, Jonathan M Davis wrote: On Wednesday, November 27, 2013 02:05:39 Adam D. Ruppe wrote: ...unless doing a new interface is on the table too. Then, we can leave std.net.curl exactly how it is, so people who use it don't have broken code, while a new std.net.http, std.net.smtp, std.net.ftp, and so on are phased in for people who want them. I could get behind that. If we were going to replace std.net.curl, I would fully expect us to end up with a new API, because the current API is what is beacuse of what curl can and can't do rather than because it's the best API for what you're conceptually trying to do. The new API might end up being fairly close to the current one, but I would not consider it desirable to try and maintain a 100% compatible API if we were replacing the current implementation except in cases where the current API is the best choice even without curl underneath it. Maybe that would be most of the API, but I'd hate to see us put ourselves in a straightjacket based on how curl works when writing an API which didn't depend on curl - particularly as writing our own would give us the opportunity to make sure that we had something that made the most conceptual sense rather than necessarily having what curl has. I definitely agree. In addition D has obtained some nice features since the definition of the std.net.curl API that I would liked have used back then. I do believe that people underestimate the work needed to make a proper http client implementation with the bells and whristles that people expect like cookie store, chuncked transfers, ssl, authentication... and handle wierd per server type bugs as well. I definitely think that a native solution is the end goal here. But if that is the case then it should be based on a proper event based system (std.event?) to support async handling (peek at how vibe has done it very nicely). But that in turn depends somewhat on allocators being well defined and implemented as I see it. -Jonas
Re: Comparison
On Wednesday, 27 November 2013 at 00:46:30 UTC, Ary Borenszweig
wrote:
On 11/26/13 7:00 PM, Namespace wrote:
On Tuesday, 26 November 2013 at 21:37:49 UTC, Jonas Drewsen
wrote:
Isn't it a bug that the assertion is triggered for this:
class Test3 {}
void main()
{
assert( (new Test3()) == (new Test3()) );
}
Tried it on http://dpaste.dzfl.pl/ as well.
/Jonas
Because your Test3 class has probably no own opEquals method,
your
comparison is the same as
assert( (new Test3()) is (new Test3()) );
which is obviously wrong.
See:
https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L116
The ddoc for the method is wrong. It should say something like:
returns != 0 if this object has the same memory address as obj.
Subclasses may override this method to provide custom equality
comparison.
Because for the OP, Test3 has the same contents as the other
Test3 (both empty).
does have the same contents as obj
yes this is what confused me... and actually, it is a bit wierd
coming from a c++ background that obj1 == obj2 is the same as
(obj1 is obj2) and not per field comparison as expected (and
documented). What is the reasoning behind this... principle of
most astonishment? :)
Re: Should std.net.curl be moved from Phobos to Deimos?
Personally I have always thought of std.net.curl as a temporary solution until a native implementation in D could be created. But I was also fully aware that people were not standing in line to make a native one and that we needed something else in the meantime. That is why I implemented it in the first place. So until there is a proper replacement in phobos I really think it should stay, since a standard library really should include networking support out of the box IMHO. /Jonas
Re: Should std.net.curl be moved from Phobos to Deimos?
On Tuesday, 26 November 2013 at 21:23:05 UTC, Adam D. Ruppe wrote: On Tuesday, 26 November 2013 at 16:39:50 UTC, Andrei Alexandrescu wrote: The problem is that long ago adding libcurl seemed like a perfectly reasonable option, particularly considering that we didn't (and we don't) have anything to replace it. Meh, doing the http and smtp stuff isn't rocket science. I did a little http library in ~300 lines on my github that some D programmers who don't want curl use. Yes - basic http, smtp is easy. But have a look at the libcurl API docs and think about how many lines it would take to implement that in D.
Comparison
Isn't it a bug that the assertion is triggered for this:
class Test3 {}
void main()
{
assert( (new Test3()) == (new Test3()) );
}
Tried it on http://dpaste.dzfl.pl/ as well.
/Jonas
Re: Improved Phobos dox
On Monday, 16 September 2013 at 17:08:38 UTC, H. S. Teoh wrote: On Mon, Sep 16, 2013 at 06:49:01PM +0200, Vladimir Panteleev wrote: On Monday, 16 September 2013 at 16:44:56 UTC, Andrei Alexandrescu wrote: I don't find disagreement with what I said. [...] Nice, but what I see here is different, not better. I think we may be disagreeing regarding different things. You could use both (dl class=d_decl) if you like. I guess 'dl class=d_decl' is one iota more specific than 'div class=d_decl' and would help if one wanted to view the HTML without any accompanying CSS. I doubt this is a goal to pursue. I refer to my original argument about how this is borderline-nitpicking. I'd like to add, however, that user-agents such as screen readers might behave better when using appropriate HTML tags. I can attest to that. I'm on another mailing list where one of the list members is sight-impaired, and she complains about how some websites (i.e. those that suffer from heavy divitis and spanitis) simply can't be read in any sane way by the screen reader. Using built-in semantic tags like dl can make a world of difference for these users, since the screen reader has no idea what class=d_decl means, but it *does* know what dl means. I wouldn't be so quick to dismiss it. Haven't followed the thread closely but one thing I've missed when trying to define a nicer stylesheet is something more specific that d_decl. d_decl is used for all declarations which means that you cannot style enums, templates, functions etc. differently in the docs. It would be nice to have an additional class added to the class attribute. For example: class=d_decl d_enum or class=d_decl d_template. /Jonas
Re: new DIP47: Outlining member functions of aggregates
3. Parameter names need not match. I think we should be conservative and require that parameter names match. This will ensure that code will not break in the future if named parameter functionality is added to the language at some point.
Re: I'm porting some go code to D
On Saturday, 24 August 2013 at 13:26:32 UTC, bearophile wrote: David Nadlinger: It's a cute idea, but not really practical, I'm afraid – Goroutines are managed by a scheduler in the Go runtime library, whereas D threads directly map to OS threads. Can't Rory McGuire add a scheduler to his code? How much code does it take? It would be very nice to have a builtin scheduler in the runtime. It would make async non-threaded programming so much nicer in D. /Jonas
Re: Ideas for a brand new widget toolkit
On Tuesday, 20 August 2013 at 13:19:33 UTC, Adam D. Ruppe wrote: On Friday, 16 August 2013 at 22:22:06 UTC, Jonas Drewsen wrote: Awesome... looking forward to have a look at it. I pushed the changes to my github today. Still a few little changes I want to make, but nothing major. (for example, the input enum is based on my US keyboard, so it doesn't have entries for other keys. But that's generally additive so should be be major breakage.) https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Thanks! /Jonas
Re: Ideas for a brand new widget toolkit
On Friday, 16 August 2013 at 13:56:20 UTC, Adam D. Ruppe wrote: On Thursday, 15 August 2013 at 20:09:34 UTC, Jonas Drewsen wrote: * SDL for input - would be awesome to get rid of this by using some of AdamRuppes work maybe. heh, I'm *almost* to the point where I can replace SDL for my own little games. I ported stb_truetype.h to D earlier in the week, I have some joystick input code and sound output code laying around, and once simpledisplay.d gets OpenGL context creation (probably tomorrow), that'll be almost everything I use there! Anyway though, as I write my minigui.d, I'm finally finishing simpledisplay.d's input events. (Previously, I only used that module as a quick image display thing, and the only events I was really interested in was basic click and key presses, 'a', 's', pressed, etc. But now I'm trying to write a little Text Edit control, so it needs a lot more detail.) Anyway, I'm fixing a lot of input bugs this weekend, so if you want to give simpledisplay.d a try next week, it might be useful to you then. Awesome... looking forward to have a look at it. /Jonas
Re: Ideas for a brand new widget toolkit
I've been tinkering with a GUI framework in D myself to use in my own project. This is how it looks: https://www.youtube.com/watch?v=IfloImORm74hd=1 * OpenGL * FreeType for glyphs * Text layout engine inspired by Qt * Widget layout inspired by OSX * SDL for input - would be awesome to get rid of this by using some of AdamRuppes work maybe. * Animations (by using CTFE)(The youtube video is laggy, it looks smooth on the machine). I've done this in C++ before and D rocks compared! Project layout: https://dl.dropboxusercontent.com/u/188292/Capture1.PNG https://dl.dropboxusercontent.com/u/188292/Capture.PNG It is Work In Progress but ping me if anyone would like partner up on this. I'm open to radical changes and redesigns... whatever it takes to make it awesome. I does require a bit of work to separate it out and put it on github so therefore I'm not posting a link to the source before someone is interested. /Jonas
Re: monarch dodra granted write access to phobos, druntime, and tools
Gratz
Suggesting new changelog format
Turn on the sound ;) http://starlogs.net/#D-Programming-Language/dmd /Jonas
Re: Suggesting new changelog format
On Friday, 28 June 2013 at 08:14:21 UTC, Mr. Anonymous wrote: On Friday, 28 June 2013 at 08:11:04 UTC, Jonas Drewsen wrote: Turn on the sound ;) http://starlogs.net/#D-Programming-Language/dmd /Jonas http://forum.dlang.org/post/xbadgetphtoqaodkl...@forum.dlang.org Ahh missed that one /Jonas
Re: DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu
I'm a Danish guy so there is a at least one dane using D :) /Jonas
Re: Formal Review of std.serialization
IMHO I think the tests would fit nicely into the package itself. Close to the code it tests. Do you mean in package.d? Yes, if that's possible. Actually I was thinking about just moving the test dir into the std.serialization. It shouldn't be part of the final distribution of course so the Makefiles would have to take that into consideration. /Jonas
Re: Formal Review Process
I really think that all the general stuff in the utils/core etc. packages should be merged into phobos as the very first thing and as normal pull requests to phobos. They are not serialization specific and rather small additions. After that the std.serialization part could go through normal review and would simpler to review. /Jonas
Re: User Defined Attributes (UDA) in Phobos/druntime
On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote: On 6/11/2013 12:00 AM, Jacob Carlborg wrote: Thoughts? I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions. Though I might not agree with this suggested meta-attribute thing I really think that serialization screams for using attributes to mark fields/classes as serializable. Would be sad not to have them. Jacob: Would it be doable to refactor the attribute magic in std.serialization into a separate module that could be provided as 3rd party extension to std.serialization until phobos itself is ready for attributes? /Jonas
Re: Formal Review Process
Rather what we usually do with helpers of unknown utility etc. is to keep them package/private for now and let their fate be decided separately via normal pull request process. That is an ok way to go as well. Most of the helpers are not of unknown utility though. The fact that we have no good idea where to put (if at all) an internal primitive should not (I'd say must not) postpone or undermine the review of the module/package itself. I think many of the helpers fit pretty well in some of the existing packages and it would feel more streamlined if they were moved there. I'm simply suggesting a divide and conquer technique for getting orange into phobos with the benefit of reduce review scope in the end. Getting RFC comments on orange has not been very fruitful so far and maybe reducing scope could do the trick. Just an idea. /Jonas
Re: Formal Review of std.serialization
A quick first look for now: In general I think that you should clone phobos and merge orange into std.serialize in order for us to see how it really fits into phobos. As such I think it feels more like a RFC than formal review because it couldn't possible go into phobos in its current state even if we ignored all comments from the this list. Now for something more constructive :) * I'm using some utility functions located in the util and core packages, what should we do about those, where to put them? The core package only have the core.Attribute module which defines a meta attribute which is a new concept in phobos. I guess that should either be removed or we should spawn a discussion about if we want such a thing or not. Is it possible to do without it? The util package util.use.d : I think the Use struct feels a bit like abusing the 'in' operator to work around D not supporting blocks or something else that would provide the desired syntax. Personally I think it should go. util.traits.d : Most of them should go to std.traits or use something from std.traits instead if possible util.reflection.d : Should probably be part if std.traits as well since there are already some reflection code in there. I guess std.traits should make use of the new package.d thing to split up the module into several files. util.ctfe.d : Wouldn't now where to put it. util.collection.array : should probably go into std.exception It seems all the module filenames are camel cased. They should be all lowercase. The _.d modules should probably be renamed to package.d now. * The unit tests are located in its own package, I'm not very happy about putting the unit tests in the same module as the rest of the code, i.e. the serialization module. What are the options? These test are quite high level. They test the whole Serializer class and not individual functions. IMHO I think the tests would fit nicely into the package itself. Close to the code it tests. https://dl.dropboxusercontent.com/u/18386187/orange_docs/Serializer.html Could you provide the docs formatted as it would be in dlang.org since only that way it is also possible to review formatting. Keep up the good work. I for one are really looking forward to finally getting this thing in. /Jonas
Re: Phobos Review Queue
On Saturday, 8 June 2013 at 07:30:03 UTC, Jakob Ovrum wrote: On Friday, 7 June 2013 at 22:52:47 UTC, Brad Anderson wrote: Found the description of the process: http://wiki.dlang.org/Review/Process It's somewhat vague and could probably use some standard announcement templates people could use. Looks like it's actually two weeks of review, one week of voting. I still think the module author should be able to be Review Manager though. It mentions that after review, it is up to the review manager whether or not to continue with a vote. That seems like a big conflict-of-interest decision. If I remember correctly, this has even happened before, with std.net.curl. I am pretty sure I was not the one deciding to start a vote for std.net.curl back then. Can't remember who was the review manager though.
Interesting D inspired proposal for C++14
http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-part-3.html Item N3597 /Jonas
Re: DIP 36: Rvalue References
Isn's it too strict? The following example would not work because
you cannot take the address of the parameter. But it would still
be nice to have it passed by ref and scoped:
struct Item
{
int data;
Item* next;
}
void printThem(const scope ref Item first)
{
auto it = first;
while (it)
{
std.stdio.writeln(*it);
it = it.next;
}
}
/Jonas
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
AFAIK most unix tools have two formats: long and short. long: dmd --foobar-dir=/somewhere/over/the/rainbow short: dmd -f /somewhere/over/the/rainbow Most programs supports both. I think that would be the way to go. /Jonas
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On Thursday, 11 April 2013 at 11:16:08 UTC, Andrej Mitrovic wrote: On 4/11/13, Jonas Drewsen nospam4...@hotmail.com wrote: AFAIK most unix tools have two formats: long and short. long: dmd --foobar-dir=/somewhere/over/the/rainbow short: dmd -f /somewhere/over/the/rainbow Most programs supports both. I think that would be the way to go. RDMD works on the assumption that its flags begin with -- and DMD's flags with -. There's no need to invent new short/long switches, we just need an equals sign to make it visually clear. By I think that would be the way to go I did not necessary refer to having both formats supported at the same time but simply to use the standard way that people know. Also using spaces might be a bad idea, you might end up doing the wrong thing if you call DMD incorrectly (e.g. a result of a wrong expansion in a shell script), for example: $ dmd -of foo.d bar.d Currently this is an error, the user forgot to specify the -of switch. If spaces were ok then this becomes the equivalent of: $ dmd -offoo.d bar.d I'd rather be safe than sorry and allow either -offoo or -of=foo. It will catch errors this way rather than do something unexpected. You may not like using spaces but it is a widespread standard and I think deviating is not the way to go. Anyway - this is turning into a bikeshed coloring discussion I guess :) /Jonas
Re: File compare/merge
In my experience p4merge from Perforce can resolve more conflicts automatically that many of the other tools I've tried. /Jonas
