Re: Proposal for porting D runtime to WebAssembly
On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote: This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d On the GC part. It says "The only unknown part is how to dump the registers to the stack to ensure no pointers are held in the registers only." Please correct me where I'm wrong, but on the level of WebAssembly there are no registers, there is an operand stack outside the address space, there are local variables to the current function, again outside the accessible address space of program's linear memory, and there is the linear memory itself. So scanning the stack becomes a really hard (should I say impossible?) part. What some compilers do is they organize another stack manually in the linear memory and store the values that would otherwise be on the normal stack, there. Which means in case of D you'll have to seriously change the codegen, to change how local variables are stored, and to use a kind of shadow stack for temporaries in expressions that may be pointers. Do you really have a plan about it?
Re: fearless v0.0.1 - shared made easy (and @safe)
On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote: I was envious of std::sync::Mutex from Rust and thought: can I use DIP1000 to make this work in D and be @safe? Turns out, yes. Nice! I spent a few minutes playing with the example and trying to break it, make the pointer escape, but I couldn't, the compiler caught me every time. This DIP1000 thing seems to be working!
Re: Release D 2.078.1
On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote: Glad to announce D 2.078.1. The Windows 7z archive version now has much simpler sc.ini, in fact too simple. With Visual C++ 2015 x64 Native Build Tools now trying to run dmd -m64 hi.d I get LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: linker exited with status 1104 So I needed to edit sc.ini and add back LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64" to the [Environment64] section. Then it went just as 2.078.0 - still missing legacy_stdio_definitions.lib that I need to add manually in the command line.
Re: ArithEval v0.5.0 released
On Sunday, 7 January 2018 at 20:41:57 UTC, Dechcaudron wrote: It allows the runtime evaluation of simple math expressions like `1 + 2 * 3` or `1 ^ foo`, with foo being given values at run time. That's a nice exercise in using Pegged. Reminds me of another Pegged-based calculator with variables, more operations, more precision and more permissive license: http://code.dlang.org/packages/pc It hasn't been updated in 4 years but still can be built by Dub automatically, that's how stable D is these days!
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 08:15:50 UTC, Rainer Schuetze wrote: What's missing is probably legacy_stdio_definition.lib that has to be added to the linker command line for VS2015 or later. Yes, that is the case! Using -v flag I can see that dmd 2.077 invokes C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\link.exe /NOLOGO app /OUT:"app.exe" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\10.0.10240.0\ucrt\x64" legacy_stdio_definitions.lib While the new 2.078 just C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /NOLOGO app /OUT:"app.exe" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\um\x64" Please try replacing the Environment64 section in sc.ini with just this: [Environment64] LIB=%@P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF I'm using the variant from 7z archive (not installer). Its sc.ini section already looks very much like this.
Re: Release D 2.078.0
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote: Glad to announce D 2.078.0. This release comes with runtime detection of Visual Studio installation paths I've got a problem with linking phobos64.lib now. I run "Visual C++ 2015 x64 Native Build Tools Command Prompt", i.e. cmd.exe with environment set up. With dmd 2.077.0 I run "dmd app.d -m64 -ofapp.exe" and it all goes well, compiles and links successfully. With dmd 2.078.0 I run "dmd app.d -m64 -ofapp.exe" and get: phobos64.lib(stacktrace_196a_3e5.obj) : error LNK2019: unresolved external symbol snprintf referenced in function _D4core3sys7windows10stacktrace10StackTrace13resolveNoSyncFAxmZAAa phobos64.lib(parseoptions_bee_21b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(demangle_ab0_79b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(parseoptions_bee_21b.obj) : error LNK2019: unresolved external symbol sscanf referenced in function _D4core8internal12parseoptions5parseFNbNiAxaKANgaKfQkZb app.exe : fatal error LNK1120: 2 unresolved externals Error: linker exited with status 1120
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Tuesday, 31 January 2017 at 13:27:31 UTC, Sönke Ludwig wrote: 0.7.31 will work with 2.069-2.073 and 0.8.0 will work with 2.070-2.073. This is especially interesting because GDC master is still on 2.069.x. Thanks!
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: For anyone who does not depend on old D frontends, it is strongly recommended to switch to the 0.8.x branch What do you mean here by "old D frontends"? What are minimal dmd versions for 0.7 and 0.8 branches?
Re: Project Highlight: Voxelman
On Saturday, 31 December 2016 at 14:22:40 UTC, jkpl wrote: What I mean is that there's a compilation error related to dlib: What's your compiler version? Many libraries and projects are not building with dmd 2.072 yet, but they build fine with dmd 2.071.
Re: unDE 0.1.0: original file manager, image and text viewer
On Thursday, 15 December 2016 at 20:16:10 UTC, unDEFER wrote: Hello, my dear friends! So many days you answers on many my questions. And today I glad to present my work: unDE 0.1.0. It is very original file manager, image and text viewer. More information: http://unde.sourceforge.net/en/ch24.html Video with English subtitles: https://youtu.be/29zuxU9eyXo Interesting, but requiring Cygwin on Windows is a no go. You're reducing your potential Windows userbase by 99%.
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 00:56:02 UTC, Guillaume Piolat wrote: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html Great post and useful pieces of code, thanks! "every class object's destructor is assumed to throw exceptions and use the GC by default." This is the schizophrenic part of D, since allocations inside destructors are not allowed by its own runtime and cause immediate stop of the program. A sane language would either insist on making all destructors @nogc or allow some allocations during the GC phase (like CLR and JVM do, I suppose). And exceptions in destructors should not be allowed: there is no sane place to catch and handle exceptions arising during the GC phase (which can be triggered by arbitrary allocation anywhere in the code), so if we can't reason about them and handle them we shouldn't allow them.
Re: Release D 2.072.0
On Monday, 7 November 2016 at 18:55:29 UTC, Anonymous wrote: To be honest, I know that the D world existed before me, and I know that it'll still exist if I leave. Between, 2.072 is the worst release I've ever seen. Yep. I tried 2.072 on a current DLangUI project under Win32. Compiled fine, but at runtime - exception, exception, exception, crash, crash, crash. Nothing works (what worked ok with previous dmd). Ran away screaming, back to 2.071. Sorry. I might try exploring the issues a bit later, can't do right now.
Re: The DLang UPB Languages and Systems Research Scholarship
On Wednesday, 26 October 2016 at 01:11:05 UTC, Mike Parker wrote: For anyone tempted to share this on /r/programming, please wait! I hope to do a blog post about this on Friday, so I'll post to reddit then. Thanks! Please don't. This is a total offtopic for /r/programming, don't create the reputation "dlang seeks for attention and spams with irrelevant stuff".
Re: [GSoC] Precise GC
On Tuesday, 6 September 2016 at 14:56:15 UTC, jmh530 wrote: GC (and runtime in general) has no idea what code is safe and what code is system. GC works with data at run-time. All @safe-related stuff is about code (not data!) and happens at compile-time. They are completely orthogonal and independent, as I understand. I don't see why you wouldn't be able to use compile-time information like __traits with the runtime. In my head, I imagine that at compile-time you can figure out which unions are in @safe functions, add a UDA to each (so you're marking data, not code), and then read that information at run-time (like with __traits). UDAs are also purely compile-time, they don't exist as run-time data.
Re: [GSoC] Precise GC
On Friday, 2 September 2016 at 14:55:26 UTC, jmh530 wrote: Anyway, with @safe unions, my thinking is that it would mean that the garbage collector can be made precise in @safe code in a way that it can't in @system code (assuming unions with pointers aren't snuck in through @trusted). GC (and runtime in general) has no idea what code is safe and what code is system. GC works with data at run-time. All @safe-related stuff is about code (not data!) and happens at compile-time. They are completely orthogonal and independent, as I understand.
Re: [GSoC] Precise GC
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote: Hi everyone, I know I'm super late to the party for this, and sorry for that. While my work on the precise GC didn't go as planned, it is closer than it was to be getting merged. My open PR for the actual inclusion of the precise GC is here: https://github.com/dlang/druntime/pull/1603 So what's its current state, how is it different from the version Rainer had years ago? Is stack scan precise? Are closures scanned precisely? What about unions? We'd be happy to see some overview of this version, what it does and how it succeeds (or fails).
Re: GSoC 2016 - Precise GC
On Sunday, 8 May 2016 at 11:16:56 UTC, deadalnix wrote: Ones that have only pointers are probably OK too. Though I'm not sure if a precise scanner takes into account the type of the pointer. I would expect it to use embedded typeinfo in target block. -Steve Because of void* and classes, the GC MUST be able to find out what type was actually allocated, or at least its pointer bitmask. Yep, and it does that by looking at metadata of the pointed object itself, it doesn't care about the type of pointer to that object. I mean if we have object x of class X in heap and pointers "X p1", "void* p2" and "Y p3" all having same value (pointing to the same address) then GC will have no problem in scanning x as long as it can access x's type info knowing the address of x in heap. Which means all p1, p2 and p3 might easily be just at one position in a union and that would not be a problem.
Re: Commercial video processing app in D (experience report)
On Thursday, 5 May 2016 at 18:33:44 UTC, TheGag96 wrote: On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: (snip) Sorry to bump this thread, but how did you handle multiple windows using DlangUI? (As in, were you able to prevent input on the main window while another one was open, etc.) I know Vadim/buggins is working on improving that right now but I'd like to know if there's a clean way to handle more than one window already. In our case there is one main window and a few other windows get opened one at a time (Platform.instance.createWindow with WindowFlag.Modal), increasing number of open windows to 2, and sometimes native dialogs are invoked in addition to the 2 DLangUI windows. I remember there was some glitches like if you press Enter in OS-native file dialog and it gets closed then an odd Enter key press message may be received by DLangUI window, but we used one simple trick: before opening some modal window change focus in current window to something harmless. After that everything worked quite well. But we're not using more than one active (i.e. not shadowed by a modal one) window at a time, so don't meet with issues you might meet there.
Re: Commercial video processing app in D (experience report)
On Thursday, 28 April 2016 at 06:22:18 UTC, Relja Ljubobratovic wrote: Can you share with us some of your experience working on image and video processing modules in the app, such as are filters here: http://www.infognition.com/VideoEnhancer/filters.html If I may ask, was that part implemented in D, C++, or was some 3rd party library used? Thanks! The filters listed there are third-party plugins originally created for VirtualDub ( http://virtualdub.org/ ) by different people, in C++. We made just 2-3 of them, like motion-based temporal denoiser (Film Dirt Cleaner) and Intelligent Brightness filter for automatic brightness/contrast correction. Our most interesting and distinctive piece of tech is our Super Resolution engine for video upsizing and it's not in that list, it's built-in in the app (and also available separately as plugins for some other hosts). All this image processing stuff is written in C++ and works directly with raw image bytes, no special libraries involved. When video processing starts our filters usually launch a bunch of worker threads and these threads work in parallel each on its part of video frame (divided into horizontal stripes usually). Inside they often work block-wise and we have a bunch of template classes for different blocks (RGB or monochrome) parameterized by pixel data type and often block size, so the size is often is known at compile-time and compiler can unroll the loops properly. When doing motion search we're using our vector class parameterized by precision, so we have vectors of different precision (low-res pixel, high-res pixel, half-pixel, quarter-pixel etc.) and type system makes sure I don't add or mix vectors of different precision and don't pass a half-pixel-precise vector to a block reading routine that expects quarter-pixel precise coordinates. Where it makes sense and possible we use SIMD classes like F32vec4 and/or SIMD intrinsics for pixel operations. Video Enhancer allows chaining several VD filters and our SR rescaler instances to a pipeline and it's also parallelized, so when first filter finishes with frame X it can immediately start working on frame X+1 while the next filter is still working on frame X. Previously it was organized as a chain of DirectShow filters with a special Parallelizer filter inserted between video processing ones, this Parallelizer had some frame queue inside and separated receiving and sending threads, allowing the connected filters to work in parallel. In version 2 it's trickier, since we need to be able to seek to different positions in the video and some filters may request a few frames before and after the current, so sequential pipeline doesn't suffice anymore, now we build a virtual chain inside one big DirectShow filter, and each node in that chain has its worker thread and they do message passing to communicate. After all, we now have a big DirectShow filter in 11K lines of C++ that does both Super Resolution resizing and invoking VirtualDub plugins (imitating VirtualDub for them) and doing colorspace conversions where necessary and organizing them all into a pipeline that is pull-based inside but behaves as push-based DirectShow filter outside. So the D part is using COM to build and run a DirectShow graph with all the readers, splitters, codecs and of course our big video processing DirectShow filter, it talks to it via COM and some callbacks but doesn't do much with video frames apart from copying. Btw, if you're interested in an image processing app in pure D, I've got one too: http://www.infognition.com/blogsort/ (sources: https://bitbucket.org/infognition/bsort )
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 15:57:19 UTC, Christof Schardt wrote: Just a question: When working with C++, did you use VisualAssist? I've used it previously in earlier VS versions but not in VS2010. VisualAssist is really great, I agree. VisualD is far from it but at least it's better than C++ support in plain VS2010 without VA.
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 13:04:27 UTC, FreeSlave wrote: Screenshots are so blurred. They are not. Just click to enlarge, your browser blurred them while resizing.
Commercial video processing app in D (experience report)
Hi, I just wanted to share some experience of using D in industry. Recently my little company released version 2.0 of our flagship product Video Enhancer, a video processing application for Windows, and this time it's written in D. http://www.infognition.com/VideoEnhancer/ Couple of screenshots: http://data.infognition.com/VideoEnhancer/ve2d-filters.jpg http://data.infognition.com/VideoEnhancer/ve2e-save.jpg Version 1 was born like 10 years ago and was of course written in C++. It consisted of main GUI executable and 5 dynamically loaded DirectShow filters. For GUI version 1 used MFC and a third-party skinning engine. This skinning engine had its own problems but since we didn't have its sources we couldn't fix them, meanwhile its author disappeared in sands of time. So when time has come to create version 2 I chose the best available language and an open source GUI library with 100% control and customizability - DLangUI. Overall, I'm pretty happy with this choice. Version 2 is quite different from v1 in feature set and internal structure, it's not a direct translation. It consists of two executables running in tandem (one does GUI, the other deals with video) and 2 dynamically loaded DirectShow filters. Both main executables are purely in D, while the DirectShow filters are still in C++. Heavy number crunching, including our main feature - motion-based video upscaler - is still in C++, because of heavy SIMD usage and Intel compiler. Main executable of version 1 was ~34K lines of C++ (half of which were libraries like pugixml) and full build took ~90 seconds. Main executables of version 2 are in total ~7.5K lines of D (of which 2K are auto generated by IDL2D tool) and full build of GUI app takes 7 seconds (and the worker app builds in 3-4 seconds), so that's a really nice improvement. Thanks to Phobos we don't need many libraries: things like XML parsing, ZIP unpacking and many others are all covered by the standard library. Only two additional libraries were used: Cerealed for serialization of messages the two processes exchange, and DLangUI. Some things to reflect on: Compiler Compiler used is DMD 2.070, 32-bit target. Video Enhancer supports 200+ plugins from VirtualDub and they happen to be 32-bit, so our app has to be 32-bit too. Speed of code generated by DMD is more than enough, even debug builds were fast enough. The default linker is used (not the MS one), and I was worried there might be some troubles with antivirus false positives (that happened before when using optlink) but no, everything went smooth and no problems with optlink arose whatsoever. IDE Visual Studio 2010 with VisualD. I've used this combo for many years, generally quite successively. Last year its D parser had some problems that made it crash on code that used DLangUI, and that was painful. I even made a patch that made the crash silent, so VisualD would silently reload the parser and continue working. It worked, but luckily authors of D parser and VisualD quickly found the crash cause and fixed it, since then everything works smoothly out of the box. I like how well DML works there, with syntax highlighting and autocompletion: http://data.infognition.com/VideoEnhancer/dml.png Builds We're not using Dub to build the app, it tends to be slow and rebuild dependencies too often (or maybe I just haven't learnt to use it properly). Instead we use Dub to build the libraries and produce .lib files, then reference libraries sources and lib files in VisualD project of the main apps and then use VisualD's simple building process that just invokes DMD. Cerealed This compile-time-introspection-based serializaition lib is really great: powerful and easy to use. We're probably using an old version, haven't updated for some time, and the version we use sometimes had problems serializing certain types (like bool[], IIRC), so sometimes we had to tweak our message types to make it compile, but most of the time it just works. DLangUI Very nice library. Documentation is very sparse though, so learning to use DLangUI often means reading source code of examples and the lib itself, and sometimes even that's not enough and you need to learn some Android basics, since it originates from Android world. But once you learn how to use it, how to encode what you need in DML (a QML counterpart) or add required functionality by overriding some method of its class, it's really great and pleasant to use. Many times I was so happy the source code is available, first for learning, then for tweaking and fixing bugs. I've found a few minor bugs and sent a few trivial fixes that were merged quickly. DLangUI is cross-platform and has several backends for drawing and font rendering. We're using its minimal build targeted to use Win32 API (had to tweak dub.json a bit). We don't use OpenGL, as it's not really guaranteed to work well on any Windows box. Using just WinAPI makes our app
Re: DlangUI on Android
On Saturday, 23 April 2016 at 18:16:38 UTC, Chris wrote: Anyone interested in taking DlangUI and turning it into something like Swing/JavaFX for D? What exactly do you mean by that?
Re: Release D 2.070.0
On Sunday, 31 January 2016 at 00:13:46 UTC, Dicebot wrote: NB: tagged commit has 2.069 in VERSION file resulting in built compiler reporting wrong version. I have added a workaround in packaging script for now but would be nice to fix that in 2.070.1 Btw, dmd.exe 2.070.0 when run says Copyright 1999-2015, even though it's released in 2016.
Re: Walter on his experience as a dev, on running an open source project and D
On Wednesday, 20 January 2016 at 11:07:16 UTC, Rikki Cattermole wrote: From what Walter said, they all knew c. So not really too low level for them. To me it looked like: Walter: "You all write in C, right?" Audience silent with expression on their faces "What is C? We've only heard about JavaScript". ;)
Re: Damage Control: An homage to Rampart (Alpha)
On Thursday, 31 December 2015 at 16:43:53 UTC, rcorre wrote: Its very incomplete, but if you don't mind spending a few minutes trying it out I'd really appreciate it. Any feedback is appreciated -- either drop a comment here or file an issue on Github. There's no included tutorial as I'm hoping the gameplay will be pretty self-evident (let me know if it isn't!). It works fine for me on Win 8.1. But I have no idea what's going on in the game, gameplay is totally unknown to me. ;)
Re: let (x,y) = ...
On Monday, 23 November 2015 at 16:58:43 UTC, Andrea Fontana wrote: Nice. Why first enforce is "==" rather than ">=" ? This prevents something like: auto arr = ["hello", "world", "!"]; let (hello, world) = arr; The very first post of this thread should have answered this. Two options are available: one requires exact number of elements and so catches more errors, the other requires there to be "enough" data, for cases where you want that. To get behavior you described just use let (hello, world)[] = arr;
Re: let (x,y) = ...
On Sunday, 22 November 2015 at 18:47:34 UTC, visitor wrote: What is the reason for using pointers (alias pointerOf(T) = T* etc...) it works without ! what am i missing ? What and how exactly works without? My original solution remembers in the constructor addresses of variables to fill, then does the filling in opAssign operator, so I needed a way to store the references and used pointers for that.
Re: let (x,y) = ...
On Monday, 23 November 2015 at 22:32:57 UTC, visitor wrote: On Monday, 23 November 2015 at 20:10:49 UTC, visitor wrote: Andrea Fontana(s allows let (hello, world) = ["hi", "there", "!"]; of course in your version let (hello, world)[] = ["hi", "there", "!"] works but for consistency with range, i think Fontana's note is relevant Well, I believe it's a matter of taste. By allowing different number of elements there you allow more errors to sink in without gaining anything at all. You lose the choice between strict and loose operators, erase the difference. It's not the "consistency" I would like to have.
Re: let (x,y) = ...
On Monday, 23 November 2015 at 11:12:33 UTC, visitor wrote: My original solution remembers in the constructor addresses of variables to fill, then does the filling in opAssign operator, so I needed a way to store the references and used pointers for that. yes, but you are using ref : "auto let(Ts...)(ref Ts vars)" so vars are changed, no need to store anything, no? i was wondering if there is some subtleties or efficiency reasons for using pointers Thanks for the code! Yep, this way it works too, by capturing input vars in a closure. So the main difference is that your variant allocates GC memory while original variant does not allocate anything in the heap (only on stack).
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:30:30 UTC, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: 3
Re: Is there a smart way to process a range of range by front ?
On Wednesday, 23 September 2015 at 20:44:07 UTC, BBasile wrote: I was thinking to a general *interleave()* algorithm for any compatible Range of Range but I can't find any smart way to process each sub range by front, eg: Is it possible ? What exactly shall your function do? How is it different from http://dlang.org/phobos/std_range.html#.transposed and http://dlang.org/phobos/std_range.html#roundRobin ?
Re: Go 1.5
On Saturday, 19 September 2015 at 09:22:40 UTC, Ola Fosheim Grøstad wrote: Please, let's stop pretending you only have to scan the GC heap. You have to scan all pointers that somehow can lead to something that can lead to something... that points into the GC heap. Yes, good point. One should keep root ranges small too. If we carefully use addRoot() and addRange() for data directly pointing to GC heap I think we don't need to let GC scan everything that can lead to this data. This is error-prone in general, of course.
Re: Go 1.5
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote: The new GC in Go 1.5 seems interesting. What they say about is certainly interesting. They went the way of classical GC-ed language where write barriers are used actively, allowing to make concurrent, incremental and (eventually, if not yet) generational GC. However it has a cost - pointer field updates are slower than in plain C/C++/D, and overall speed is close to Java. D tries to be like C and C++ where simple code is fast and straightforward, there are no write barriers and there will never be, without changing the language design. It means D's GC will always be dog slow - it has to stop the world and scan full heap every time. And that leads to different usage pattern where GC heap should remain small and GC allocation rate low.
Re: Blog post : OOP composition with mixins
On Monday, 24 August 2015 at 16:21:04 UTC, Dejan Lekic wrote: What I think D community would benefit from would be a series of Idiomatic D articles. This collection of short pieces comes to mind: http://p0nce.github.io/d-idioms/
[blog post] Dependent types in (half of) D
I had this idea for a long time but a recent talk about a real dependently typed language helped me with nice examples to demonstrate on. The interpreted part of D is actually dependently typed! http://www.infognition.com/blog/2015/dependent_types_in_d.html
Re: [blog post] Dependent types in (half of) D
On Thursday, 30 July 2015 at 13:25:31 UTC, Timon Gehr wrote: There is no dependent typing here. Failures occur during interpretation. Type theory doesn't say anything about interpretation and compilation. Are you saying there cannot be an interpreted dependently typed language? (hint: Idris has a REPL) Also, during compilation dependently typed languages evaluate a lot of code (do CTFE in D terms), and some fails occur during this process. So this is not the real difference.
Re: [blog post] Dependent types in (half of) D
On Thursday, 30 July 2015 at 16:13:46 UTC, Timon Gehr wrote: You need to consider the type system and the evaluation semantics. What are they for the interpreted meta-programming part of D? (I can find the semantics, but not a non-trivial type system.) Yes, this is what interests me too. The real difference is (roughly!) that the dependently typed interpreted program always fails If there is some execution in which it would fail. (assuming type-safety). Dynamically typed interpreted languages on the other hand only fail if the particular execution exposed fails. This is what we are looking at here. I feel it too, but is this really about dynamic/dependent _types_ or is it about static/dynamic checking? This is probably more about compilation semantics than actual type system. Also, if we have some code paths that are incorrect but never used during compilation, isn't it a guarantee they will never be used at all at runtime so the compiled program is correct? (I'm not sure about all this)
Re: Visual D 0.3.41 released
On Saturday, 16 May 2015 at 09:09:38 UTC, Rainer Schuetze wrote: there is a new release of Visual D available at http://rainers.github.io/visuald/visuald/StartPage.html Great, thank you very much for your work!
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. See the changelog for more details. http://dlang.org/changelog.html I don't see any mention of DIP25 here (Sealed references - return ref arguments etc.). Was it implemented and included in this release?
Re: let (x,y) = ...
On Thursday, 19 February 2015 at 09:46:13 UTC, Ola Fosheim Grøstad wrote: On Thursday, 19 February 2015 at 04:38:32 UTC, thedeemon wrote: let (name, age) = getTuple(); Maybe change the name to tie: http://www.cplusplus.com/reference/tuple/tie/ ? SML, OCaml, Haskell, F#, ATS, Rust, Swift and others have it as let keyword, so personally I'd prefer continuing that tradition.
Re: let (x,y) = ...
On Thursday, 19 February 2015 at 09:31:59 UTC, ponce wrote: That's pretty neat! May I turn this code into a d-idioms? Name and link will be kept of course. Sure, if you wish. There was just one person using this thing until today, so I dunno whether it deserves to be in that list.
let (x,y) = ...
Creating tuples and returning them from functions is trivial in D:
auto getTuple() { return tuple(Bob, 42); }
but using them afterwards can be confusing and error prone
auto t = getTuple();
writeln(name is , t[0], age is , t[1]);
I really missed the ML syntax to write
let (name, age) = getTuple();
Turns out this is ridiculously easy to implement in D, so here's
my very tiny module for this:
https://bitbucket.org/infognition/dstuff/src (scroll down to
letassign.d)
It allows you to write:
int x, y, z, age;
string name;
let (name, age) = getTuple(); // tuple
let (x,y,z) = argv[1..4].map!(to!int); // lazy range
let (x,y,z) = [1,2,3]; // array
SomeStruct s;
let (s.a, s.b) = tuple(3, piggies);
If a range or array doesn't have enough elements, this thing will
throw, and if it's not desired there's
let (x,y,z)[] = ...
variant that uses just the available data and keeps the rest
variables unchanged.
Re: dfl2 is comming
On Wednesday, 15 October 2014 at 23:44:47 UTC, FrankLike wrote: https://github.com/FrankLIKE/dfl2 select the master. Thank you. There were 15 forks of DFL on github (some of them working fine with 2.066), you made a 16nth, with another name. ;) What's the point? Btw, your version (just like most others) contains bugs causing the app to crash on exit. The issue is with destructors (in Timer and Tooltip, for example) that try to access some global/static variables, and when the app closes GC does its final cycle and calls destructors, and at this time many of those objects are already dead. It went silent in older versions of D, but since 2.065 was pretty visible. My fix is here: https://github.com/thedeemon/dfl/commit/290d6456f6d13447311845929fd929acb6938a5d (sadly, combined with additional changes I made when trying to find the bugs)
Re: D2 port of Sociomantic CDGC available for early experiments
Gentlemen, do I understand correctly that you're trying to find a Windows-friendly switch to something that will never see the light on Windows (because of being based on fork)?
Re: early alpha of D REPL
On Wednesday, 12 February 2014 at 04:43:00 UTC, cal wrote: On Tuesday, 11 February 2014 at 11:33:53 UTC, thedeemon wrote: Have you seen Dabble? https://github.com/callumenator/dabble Just found out its author added Linux support. I was able to build an x86 version but it didn't work properly in a 64 bit system: it assumes dmd makes x86 binaries by default while it really makes 64-bit ones. I don't have a 64-bit tool-chain to play with, could submit those 64 bit build errors on github? I've just submitted a pull request for compiling dabble repl in 64 bits and created an issue on github with the linking problem arising when it tries to work. My diagnosis of the problem might be absolutely wrong though.
Re: early alpha of D REPL
Have you seen Dabble? https://github.com/callumenator/dabble Just found out its author added Linux support. I was able to build an x86 version but it didn't work properly in a 64 bit system: it assumes dmd makes x86 binaries by default while it really makes 64-bit ones. And for 64 bits Dabble doesn't compile: as it often happens, it's too easy to forget that array.length is not always uint.
Re: Scriptlike: New lib to aid in writing script-like programs
On Tuesday, 11 February 2014 at 11:38:06 UTC, Nick Sabalausky wrote: I've released a little one-module utility, Scriptlike, to help simplify writing shell script-like programs in D: https://github.com/Abscissa/scriptlike Sounds very nice and handy. I tend to write my scripts in D these days, often migrating them from Ruby, and this lib might be helpful. Thanks for putting it up!
Re: Crystal
On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig wrote: One time I asked in this newsgroup if it was possible to have an auto keyword for function/method arguments. And... why not make all functions/methods be templates on the type of its arguments? I think nobody liked this idea. I said Ruby is like this: you never specify types in method definitions. I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? I think everyone who wants to create languages should first familiarize himself with ML family of languages and especially OCaml. It's got global type inference done right, you can write big programs never specifying types of arguments of functions, they all got inferred, and not just to first occurrence but to most general (polymorphic) form. The compiler is incredibly fast and generated code is pretty fast too (approximately as fast as Java). Things to learn: Damas-Hindley-Milner, structural typing, row polymorphism. So your questions are already answered ages ago: yes, it is possible to have static typing with conciseness of dynamic languages, speed of static languages and a fast compiler which inferences types. Also, knowing OCaml will make your life much easier as a compiler developer. Writing compilers is much much easier and more convenient in ML than in Ruby, I know it from first-hand experience, I did both in the past.
Re: A look at the D programming language by Ferdynand Górski
On Monday, 7 January 2013 at 22:14:46 UTC, Ali Çehreli wrote: On 01/07/2013 01:57 PM, Phil Lavoie wrote: I meant scope objects work fine in most cases, but sometimes its good to explicitly delete objects on the heap. Usually, what is needed is to just finalize the object. The memory that it sits on should still be managed by the GC. This is all fine when GC is precise. With current GC in 32 bits I'd rather have manual deallocation than leaks. This is actually what I successfully did in a photo editing app: using 'delete' for large chunks of data (uncompressed photos) and GC for the rest. This way everything worked smoothly.
Re: A look at the D programming language by Ferdynand Górski
On Monday, 7 January 2013 at 11:31:46 UTC, bearophile wrote: There is also Rust. I had the impression that Rust was at embryonic stage where it changes all the time, can't really live by itself and is not born yet. It's an interesting project but not a language one would use today for real work. Or am I mistaken?
Re: Visual D 0.3.35 released - semantic analysis considered stable
Fixed here: http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.36rc2.exe Fixed indeed. Thanks a lot!
Re: vibe.d 0.7.10 released
Great news, keep up the good work! Last month I used previous version to make a simple online app for one contest. I developed in Windows and deployed in Linux (a small VPS, installed dmd from some package and vibe.d from the zip archive). I had only a few hours to make that app and everything worked very smoothly. The app is still running and after a few weeks of work its memory usage is still just a few MBs, and CPU load was always close to 0% (I don't have much traffic there though). Thank you for a great product! My only nuisance was a clash of some DLLs in the path between vibe.d and Visual-D. After adding vibe.d dir to system path Visual-D started to crash. Have to keep them separated.
Re: Visual D 0.3.35 released - semantic analysis considered stable
After switching to this version it started to build my windows app as a console one. It seems to ignore the subsystem choice, I don't see any mention of -L/SUBSYSTEM: in generated build scripts anymore. Previously I had 0.3.33, I guess, which compiled and linked in one go, not in separate steps, it worked fine.
Re: DConf 2013 on kickstarter.com: we're live!
On Monday, 22 October 2012 at 17:25:28 UTC, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! I'm a backer now, with Facebook and Amazon accounts it was real quick and simple. My evil plan is the fact of organizing this conference will bring more people's attention to the language, more adopters and developers, so the implementation will get better and better faster.
Re: Visual D 0.3.34 released - powered by a precise garbage collector
On Friday, 12 October 2012 at 17:37:09 UTC, Rainer Schuetze wrote: after struggling with memory issues for too long, the newest version of Visual D enjoys the benefits of a pretty precise garbage collector. Great news! I'm a happy thankful user of VisualD. I really like the fact that the new precise GC is being tested on a real world project, and that it happens in Windows, not yet another unix-only development. What are your thoughts on current state of precise_gc2? How stable and how fast is it? What are the current plans for it?
Re: Remus
On Tuesday, 9 October 2012 at 19:34:01 UTC, Namespace wrote: Stack Instances: There aren't many words for: if you need a stack instance, write: local Foo f = new Foo(); it's more or less the same as scope. What's the difference between this and std.typecons.scoped, except for alignment and syntax?
