Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 00:54:37 UTC, Chris Williams wrote: I didn't mean it as a solution. As said, I was just looking for an intro to the topic, so that I (and others) could meaningfully contribute or at least understand the options. I'll look up libunwind and, if that has enough info for me to grok it, create a wiki page on the subject. It is a horrible solution developed for the Itanium VLIW architecture which is very sensitive to branching. IRRC it basically works by looking at the return address on the stack, then picking up stack frame information in a global table to unwind. It is language agnostic and the language provides a personality function to unwind correctly in a language dependent manner... AFAIK, C++ exceptions are copied from the stack to a special memory region when unwinding to prevent the memory issues D suffers from. I agree that a fast unwind with stack pointer reset or multiple return paths would be much better, but you need to rewrite the backend to support it. That's the main issue... the fast path argument is just a sorry excuse that literally means that exceptions are avoided for common failures in C++. As a result you get APIs that are nonuniform.
Need help to understand how to work with tkd
Now I am trying to learn how to build GUI apps in D. But I have
some troubles.
http://code.dlang.org/packages/tkd
1. I can't understand how to set window size in example on page
above. I looked at docs and found only how to create new window.
But here I do not see any procedure that create window and set
it's params. I see only initInterface.
2. Do I right understand that all GUI stuff should be placed only
in:
class Application : TkdApplication
3. I need to get file name from dialog and use it's for example
in main
override protected void initInterface()
{
...
string fileToOpen = dialog.getResult();
}
How I can get fileToOpen from main or another instance. Could you
show example?
Re: contiguous ranges
On Tuesday, 17 February 2015 at 15:50:17 UTC, Andrei Alexandrescu
wrote:
for an array r, is r.retro contiguous or not?
I would argue that the only operations which preserve contiguity
are slicing, concatenating and appending; r.retro, r.stride,
r.map!f, etc should yield a RandomAccessRange.
I don't think this is a deal breaker, as conceptually its akin to
losing random-accessiblity under a filtering or grouping. Input
ranges are ubiquitous, RandomAccessRanges are more rare, and
ContiguousRanges are rarer still. It stands to reason that
contiguity is unlikely to be preserved under a given
transformation.
This needs, however, a few more implementations that
motivate the concept.
The main use cases I had in mind was for optimized data transfers
and passing arguments to C APIs, and in this regard the
definition of ContiguousRange would need a bit of refinement,
maybe like so:
A ContiguousRange r of type R is a RandomAccessRange which
satisfies hasLValueElements and defines a member called ptr which
satisfies the following conditions:
1) *r.ptr == r[0] r.ptr == r[0]
2) for all 0 = i r.length, *(r.ptr + i) == r[i] r.ptr +
i == r[i]
We could then have:
void load_data (R)(R r) {
static if (isContiguousRange!R)
auto ptr = r.ptr;
else {
auto cache = r.array;
auto ptr = cache.ptr;
}
some_C_lib_call (r.length, ptr);
}
and
void copy (R,S)(R r, S s) if (allSatisfy!(isContiguousRange, R,
S)) {
// type and length equality assertions
vectorized_blit (ElementType!R.sizeof, r.length r.ptr, s.ptr);
}
---
Extending the concept to multiple dimensions is thorny, but then,
I've found that the same is true for everything but
RandomAccessRanges.
Re: Need help to understand how to work with tkd
Yeah, the docs navigation sucks http://htmlpreview.github.io/?https://github.com/nomad-software/tkd/master/docs/tkd/tkdapplication.html
Re: Calypso: Direct and full interfacing to C++
Hello Elie, I just pushed a small pull request for fromTypeTemplateSpecialization. I forgot to mention in the request that the changes allow bitset.d to be compiled and run again. With those changes all the examples compile and run again. There are still two errors when compiling vector.d. Clang errors when making the pch file. LDC2 still runs and produces a working binary anyways. Not sure what you are working on, but I can look at those errors if you like. Do you have an email address I can get in touch with you at? Jump on to #ldc on IRC and pm me if you don't want to post here. I didn't look at the build errors on OS X again yet...got tired of build errors for a bit :) Thanks, Kelly
Re: DlangIDE
On 17.02.2015 20:41, Vadim Lopatin wrote: It looks like we need to develop some universal debugger library. For linux, it can use gdb as a backend. For windows - I'm not sure. Is there any console debugger which can debug dmd generated executables? I've checked windbg shipped with dmd, but it looks like it is GUI, and cannot be used as backend via console. Trying to play with my own implementation of debugger using win32 API. Probably there is already some debugger interface written in D? On Windows, there is mago (https://github.com/rainers/mago), a debug engine that integrates with Visual Studio, but it's actually not limited to that. It might be rather complicated to host it, though, you'll have to interface with IDebugEngine2 and all its subclasses (https://msdn.microsoft.com/en-us/library/bb145310.aspx). If you want a text interface, the Debugging Tools for Windows (https://msdn.microsoft.com/en-us/windows/hardware/hh852365) also contain cdb, a command line version of windbg (forget about the one distributed with dmd). For Win32, you'll have to convert the old CodeView debug info written by optlink to PDB format using cv2pdb, though.
Re: Botan Crypto and TLS for D
That's awesome ! Thanks for all the work you put in it, and more generally, in Vibe.d. 2015-02-17 22:00 GMT+01:00 Etienne via Digitalmars-d digitalmars-d@puremagic.com: I'd like to announce the first release of Botan, which implements all features of v1.11.10 in the C++ library. I gave special attention to properly translating it to correct D code. It only runs with DMD master for now, only tested on Linux x86 or x86_64, and it uses a custom allocator library called memutils which must be placed in ../ I'd also want to underline that Alexander Bothe from Mono-D put some special attention to making sure the IDE runs smoothely with Botan. All tests are passing at the time of this writing (which is thousands of tests for all algorithms, incl x509, pubkeys, tls and so on). I'll let the wiki/api docs/code talk for me, I'm off to writing an TLS driver for vibe.d now Have fun!
Re: Mimicking C++'s indexing behavior in D associative arrays
Rikki Cattermole: Foo*[string] bar; Foo v = *bar.grab(mykey); Is this the setdefault of Python dicts? If this need is strong a new function could be added to Phobos (or even druntime if you want to reduce the number of hash computations). Bye, bearophile
Re: Mimicking C++'s indexing behavior in D associative arrays
// Assume bar is some associative array of type Foo[string]
Foo* value = key in bar;
if (!value) {
bar[key] = Foo.init;
value = bar[key];
}
This seems sub-optimal, given that in involves three hashes (two lookups
and one insertion). Is there a more efficient or cleaner way to do so?
So basically:
Foo v = bar.get(key, Foo.init)
bar[key] = v;
Get is like an ordinary index but it will return the given value if it does not
exist in the AA.
Of course you probably want to create a new UFCS function to wrap your check +
default initialize if it doesn't exist.
T grab(T, U)(T[U] aa, U key) if (is(T == struct)) {
if (key !in aa)
aa[key] = new T;
return aa[key];
}
You are searching for the key twice and the original example used pointers.
There is a function called _aaGetX in the runtime that has exactly the required
behaviour:
// Get pointer to value in associative array indexed by key.
// Add entry for key if it is not already there.
void* _aaGetX(AA* aa, const TypeInfo keyti, in size_t valuesize, in void*
pkey)
however, using it in normal code could be considered a hack, because it belongs
to the internal implementation of associative arrays. Anyway, while waiting for
a better solution to present itself, we might as well have a look at this very
dirty one. ;)
extern(C) void* _aaGetX(void* aa, const TypeInfo keyti, in size_t
valuesize, in void* pkey);
V* aaGet(K, V)(V[K] arr, K key) {
return cast(V*)_aaGetX(cast(void*)arr, typeid(K), V.sizeof,
cast(void*)key);
}
unittest {
int[int] arr = [1: 10, 2: 20, 3: 30];
int *val = arr.aaGet(3); // an existing value
assert(*val == 30);
val = arr.aaGet(4); // aa[4] will be created
assert(*val == int.init);
assert(arr[4] == int.init);
}
Re: DlangIDE
On Wednesday, 18 February 2015 at 08:21:19 UTC, Rainer Schuetze wrote: On 17.02.2015 20:41, Vadim Lopatin wrote: It looks like we need to develop some universal debugger library. For linux, it can use gdb as a backend. For windows - I'm not sure. Is there any console debugger which can debug dmd generated executables? I've checked windbg shipped with dmd, but it looks like it is GUI, and cannot be used as backend via console. Trying to play with my own implementation of debugger using win32 API. Probably there is already some debugger interface written in D? On Windows, there is mago (https://github.com/rainers/mago), a debug engine that integrates with Visual Studio, but it's actually not limited to that. It might be rather complicated to host it, though, you'll have to interface with IDebugEngine2 and all its subclasses (https://msdn.microsoft.com/en-us/library/bb145310.aspx). If you want a text interface, the Debugging Tools for Windows (https://msdn.microsoft.com/en-us/windows/hardware/hh852365) also contain cdb, a command line version of windbg (forget about the one distributed with dmd). For Win32, you'll have to convert the old CodeView debug info written by optlink to PDB format using cv2pdb, though. I'll check mago, thank you!
Re: Packt is looking for someone to author a Learning D
On Wed, 2015-02-18 at 09:56 +, Kagamin via Digitalmars-d-announce wrote: […] Isn't latex for document restyling? What you would use it for? There's little time to only write the text, let alone fiddling with styles and typesetting. Word is better in this sense that it gets the end result just by saving the document. (Xe|Lua)LaTeX (or LaTeX 3) is an authoring tool, but then using the same source form it becomes a typesetting tool. No need to change the tools to change the role. LaTeX (and AsciiDoc) files are mergeable and hence can be stored in a VCS repository very easily. Word files are just binary blobs. Perhaps for individual working there is a who cares possibility, but for joint authoring a VCS repository provides a shared, managed store. VCS and binary blobs are a waste of time, so if you author with binary blobs you can't really do joint authoring, unless you impose sequential access. I have tried using a wrapper around FrameMaker files to achieve locking, technology works, authoring process sucks. Think using SCCS or RCS. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
quick-and-dirty minimalistic LISP engine
here is my little contribution to the everlasting how you shouldn't write the code contest. this is very simple (yet fully working) LISP 1 implementation. it is slow like a dead snail, it trashing memory faster than you can say WTF?!, but it does it's job. this code was ripped out of closed-source project, so no git this time, sorry. yes, it has both automatic function wrapping and ability to call LISP functions without manual list building. and yes, it is really used in real software. Public Domain / WTFPL. http://ketmar.no-ip.org/milf_for_the_masses.zip signature.asc Description: PGP signature
Re: Problem with coupling shared object symbol visibility with protection
Hi, I also want to say a big thank you to all of you involved in this topic and especially to Benjamin. Proper DLL handling in D I would really appreciate. I think this topic is the break through. Kind regards André On Tuesday, 17 February 2015 at 18:03:06 UTC, Benjamin Thaut wrote: So i looked at the Dll Test within the dmd test framework and when I make export an attribute, like I suggested, this perticular test will compile run without any code changes. This is another reason why I suspect that making export an attribute will only break very little if any code at all. Am 16.02.2015 um 09:08 schrieb Walter Bright: At this point I suggest simply making those private helper functions public and export them. It gets your project moving without waiting for language changes (and this is a breaking change). I have to big fears with doing this 1) I finish everything up any finally do the pull request. Then the reviewers will realize that using export in all required places will completely undermine D's module level protection system and reject the PR. Then all my work is in vain. 2) Even if 1 does not happen, that means from now on the broken export will be used in _actual_ code. Because it kind of works. Going forward this would mean that changing export into an attribute will break actual production code. So in my opinion we have to implement Dll Support on windows and fix export simulatiously, otherwise fixing export will lead to big breaking changes instead of a few small ones. Kind Regards Benjamin Thaut
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 08:13:35 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 18 February 2015 at 00:54:37 UTC, Chris Williams
wrote:
I didn't mean it as a solution. As said, I was just looking
for an intro to the topic, so that I (and others) could
meaningfully contribute or at least understand the options.
I'll look up libunwind and, if that has enough info for me to
grok it, create a wiki page on the subject.
It is a horrible solution developed for the Itanium VLIW
architecture which is very sensitive to branching. IRRC it
basically works by looking at the return address on the stack,
then picking up stack frame information in a global table to
unwind. It is language agnostic and the language provides a
personality function to unwind correctly in a language
dependent manner...
AFAIK, C++ exceptions are copied from the stack to a special
memory region when unwinding to prevent the memory issues D
suffers from.
I agree that a fast unwind with stack pointer reset or multiple
return paths would be much better, but you need to rewrite the
backend to support it. That's the main issue... the fast path
argument is just a sorry excuse that literally means that
exceptions are avoided for common failures in C++. As a result
you get APIs that are nonuniform.
Windows SEH maintains a per-thread linked list of exception
handlers, but the C++ runtime seems to install only one handler
at the start of every function and resorts to lookup tables if
there are multiply try{}s in the function.
If you want to avoid lookup tables, you can of course add/remove
catchers dynamically whenever you enter/leave a try block, that
would add a small cost to every try, but avoids the (larger)
table lookup cost on the catch.
Re: Need help to understand how to work with tkd
For my regret I need example to understand how to work with шею Could you show me at last passing fileToOpen to another instance?
Re: Botan Crypto and TLS for D
On Tue, 17 Feb 2015 20:14:50 -0500, Etienne Cimon wrote: So many nice projects :D We have such sights to show you! signature.asc Description: PGP signature
Re: Botan Crypto and TLS for D
On Wed, 18 Feb 2015 06:35:08 +, Joakim wrote: accompanied by benchmarks of the C++ and D code it's better to keep silence. dmd was never very good in optimising code. ;-) signature.asc Description: PGP signature
Re: Botan Crypto and TLS for D
On Tue, 17 Feb 2015 20:14:50 -0500, Etienne Cimon wrote: I'll be working on HTTP/2 with websocket-style full duplex communications once this is done, and then a CMS that has a windows explorer-like desktop front-end with a redis filesystem and distributed node management. So many nice projects :D very intriguing. this will be interesting thing to play with. and i really like your passion. ;-) signature.asc Description: PGP signature
Re: Undefined symbol?
On Wednesday, 18 February 2015 at 08:55:51 UTC, Tofu Ninja wrote: When I compile my project in release dmd suddenly starts complains about missing symbols that look like they are from phobos. Symbol Undefined _D3std9exception134__T12errnoEnforceTbVAyaa50_433a5c445c646d64325c77696e646f77735c62696e5c2e2e5cA7E6C89DF0A958C3336C905AF5DE Any idea what is causing it and what a fix might be? These errors are normally caused by combining object files or libraries that were compiled by different compiler versions. The biggest mistake is accidentally linking to an older/newer version of phobos.
Undefined symbol?
When I compile my project in release dmd suddenly starts complains about missing symbols that look like they are from phobos. Symbol Undefined _D3std9exception134__T12errnoEnforceTbVAyaa50_433a5c445c646d64325c77696e646f77735c62696e5c2e2e5cA7E6C89DF0A958C3336C905AF5DE Any idea what is causing it and what a fix might be?
Re: Dividing D Module between multiple files
On 02/17/2015 11:23 PM, Muahmmad Adel wrote: I have searched online and I found no way for dividing D Module between multiple files. As always, documentation can be better. :) There is the relatively new package module: http://dlang.org/module.html#package-module http://ddili.org/ders/d.en/modules.html#ix_modules.package%20import high probability of merge conflicts (as more developers are working on the same file) A merge conflict at the file level yes, but if the developers are touching different parts of that file, then most merge tools wouldn't see that as a merge conflict. Ali
Re: Packt is looking for someone to author a Learning D
On Sunday, 15 February 2015 at 04:38:08 UTC, Craig Dillabaugh wrote: Just my personal opinion as one who recently finished a 200 page thesis in Latex, and is now working for a company where we do all our internal documents in Word. Latex certainly has its ugly warts, but it is so nice for lengthy document1. Isn't latex for document restyling? What you would use it for? There's little time to only write the text, let alone fiddling with styles and typesetting. Word is better in this sense that it gets the end result just by saving the document.
Re: Botan Crypto and TLS for D
On 2015-02-18 11:41, Andrei Alexandrescu wrote: I'd love to add libasync to Phobos! -- Andrei Even as I add this as a dependency? : https://github.com/etcimon/memutils Instead of a single ScopedFiberPool, I intend to have ScopedPools with one stack in fiber, another in thread, and using the GC as a fallback. You can find a code example of the idea here: https://github.com/rejectedsoftware/vibe.d/issues/978#issuecomment-73819358
Re: D and GPGPU
On Wednesday, 18 February 2015 at 16:03:20 UTC, Laeeth Isharc wrote: On Wednesday, 18 February 2015 at 15:15:21 UTC, Russel Winder wrote: It strikes me that D really ought to be able to work with GPGPU – is there already something and I just failed to notice. This is data parallelism but of a slightly different sort to that in std.parallelism. std.concurrent, std.parallelism, std.gpgpu ought to be harmonious though. The issue is to create a GPGPU kernel (usually C code with bizarre data structures and calling conventions) set it running and then pipe data in and collect data out – currently very slow but the next generation of Intel chips will fix this (*). And then there is the OpenCL/CUDA debate. Personally I think OpenCL, for all it's deficiencies, as it is vendor neutral. CUDA binds you to NVIDIA. Anyway there is an NVIDIA back end for OpenCL. With a system like PyOpenCL, the infrastructure data and process handling is abstracted, but you still have to write the kernels in C. They really ought to do a Python DSL for that, but… So with D can we write D kernels and have them compiled and loaded using a combination of CTFE, D → C translation, C ompiler call, and other magic? Is this a GSoC 2015 type thing? (*) It will be interesting to see how NVIDIA responds to the tack Intel are taking on GPGPU and main memory access. I agree it would be very helpful. I have this on my to look at list, and don't yet know exactly what it does and doesn't do: http://code.dlang.org/packages/derelict-cuda What is does is provide access to the most useful part of the CUDA API which is two-headed: - the Driver API provides the most control over the GPU and I would recommend this one. If you are in CUDA you probably want top efficiency and control. - the Runtime API abstract over multi-GPU and is the basis for high-level libraries NVIDIA churns out in trendy domains. (request to Linux/Mac readers: still searching for the correct library names for linux :) ). When using DerelictCUDA, you still need nvcc to compile your .cu files and then load them. This is less easy than when using the NVIDIA SDK which will eventually allow to combine GPU and CPU code in the same source file. Apart from that, this is 2015 and I see little reasons to start new projects in CUDA with the advent of OpenCL 2.0 drivers.
deliberately failing compilation when errors are in embedded DSL
I'm developing an embedded DSL using CTFE. The DSL code is translated into D code and mixin-ed into the D code of user's application. In order to provide meaningful error messages the DSL compiler always intercepts all errors in the DSL code and reports them at compile-time using pragma(msg, ...). The DSL compiler never generates incorrect D code to avoid reporting errors in the generated D code obscurely related to the original DSL code. The problem is that the D compiler always exits as if the compilation was successful (for D compiler it is successful, since the generated D code is correct). Is there any way to force the D compiler to fail compilation other than generating incorrect D code when translating erroneous DSL code?
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 08:13:35 UTC, Ola Fosheim Grøstad wrote: It is a horrible solution developed for the Itanium VLIW architecture which is very sensitive to branching. IRRC it basically works by looking at the return address on the stack, then picking up stack frame information in a global table to unwind. It is language agnostic and the language provides a personality function to unwind correctly in a language dependent manner... Which is true, but would be as true without the horrible mention. Adjective do not constitute arguments. I agree that a fast unwind with stack pointer reset or multiple return paths would be much better, but you need to rewrite the backend to support it. That's the main issue... the fast path argument is just a sorry excuse that literally means that exceptions are avoided for common failures in C++. As a result you get APIs that are nonuniform. What you agree with is irrelevant if it do not come backed by facts. You can qualify thing as horrible, sorry excuses and so on, the only thing it is telling us is that you seems incapable of forming a compelling argument and rely on smear instead.
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote: From my POV best proposal from last lengthy discussion was to enable reference-counted non-gc-heap Exceptions. But that needs a language change because RefCounted!T is a struct and thus neither can be thrown nor can be part of Throwable class hierarchy. Any concept that implies that exceptions an be deallocated in `catch` block is absolutely unacceptable because it conflicts with exception propagation from fibers - a very important piece of functionality. RefCounted Exceptions would work quite nicely. You are right that It will require work on the language to support them but I like that solution. If you don't mind, could you explain why cleaning up exception in the catch block would break exception propogation from fibers. Are you saying that if you throw inside a catch block and save a reference to the exception (in the new exceptions next field), that it will create a dangling pointer?
Re: [NEEDING HELP] Translation of Ali Cehreli's book in French
On Tuesday, 17 February 2015 at 22:46:01 UTC, Raphaël Jakse wrote: To begin the translation of a chapter, I suggest you tell it here so two people are not translating the same chapter at the same time. Ok, I am gonna start with the Variable number of parameters chapter, then. I am thinking about using ODT/LibreOffice at the moment, since I don't know much about whata and don't have a bitbucket account yet. I'll get into this when I have some translated work to show. Regards, Olivier
Re: Issue with rendering dlang.org/library
On Saturday, 14 February 2015 at 10:25:52 UTC, Vladimir Panteleev wrote: make it stop using its own templating language and use the one we already use for everything else - HTML, PDF, Mobi, CHM - DDoc. DDoc isn't a good tool to generate webpages. For the simple reason that a webpage needs to be dynamic, i.e. handle stuff that isn't known while generating documentation. If I would run a D project that needed online documentation I would either have ddoc generate an intermediate structure or directly generate partial diet templates. I just do not see why ddoc needs to general html pages. What about single responsibility?
Re: D and GPGPU
On Wednesday, 18 February 2015 at 15:15:21 UTC, Russel Winder wrote: It strikes me that D really ought to be able to work with GPGPU – is there already something and I just failed to notice. This is data parallelism but of a slightly different sort to that in std.parallelism. std.concurrent, std.parallelism, std.gpgpu ought to be harmonious though. The issue is to create a GPGPU kernel (usually C code with bizarre data structures and calling conventions) set it running and then pipe data in and collect data out – currently very slow but the next generation of Intel chips will fix this (*). And then there is the OpenCL/CUDA debate. Personally I think OpenCL, for all it's deficiencies, as it is vendor neutral. CUDA binds you to NVIDIA. Anyway there is an NVIDIA back end for OpenCL. With a system like PyOpenCL, the infrastructure data and process handling is abstracted, but you still have to write the kernels in C. They really ought to do a Python DSL for that, but… So with D can we write D kernels and have them compiled and loaded using a combination of CTFE, D → C translation, C ompiler call, and other magic? Is this a GSoC 2015 type thing? (*) It will be interesting to see how NVIDIA responds to the tack Intel are taking on GPGPU and main memory access. https://github.com/HSAFoundation This is really the way to go, yea opencl and cuda exist, along with opengl/directx compute shaders, but pretty much every thing out their suffers from giant limitations. With HSA, HSAIL bytecode is embedded directly into the elf/exe file, HASIL bytecode can can fully support all the features of c++, virtual function lookups in code, access to the stack, cache coherent memory access, the same virtual memory view as the application it runs in, etc. HSA is implemented in the llvm backend compiler, and when it is used in a elf/exe file, their is a llvm based finalizer that generates gpu bytecode. More importantly, it should be very easy to implement in any llvm supported language once all of the patches are moved up stream to their respective libraries/toolsets. I believe that linux kernel 3.19 and above have the iommu 2.5 patches, and I think amd's radeon KFD driver made it into 3.20. HSA will also be supported by ARM. HSA is generic enough, that assuming Intel implements similar capabilities into their chips it otta be supportable their with or without intels direct blessing. HSA does work with discrete gpu's and not just the embedded stuff, And I believe that HSA can be used to accelerate OpenCL 2.0, via copyless cache coherent memory access.
Re: deliberately failing compilation when errors are in embedded DSL
On 2/18/15 12:43 PM, Dmitri Makarov wrote: I'm developing an embedded DSL using CTFE. The DSL code is translated into D code and mixin-ed into the D code of user's application. In order to provide meaningful error messages the DSL compiler always intercepts all errors in the DSL code and reports them at compile-time using pragma(msg, ...). The DSL compiler never generates incorrect D code to avoid reporting errors in the generated D code obscurely related to the original DSL code. The problem is that the D compiler always exits as if the compilation was successful (for D compiler it is successful, since the generated D code is correct). Is there any way to force the D compiler to fail compilation other than generating incorrect D code when translating erroneous DSL code? static assert(0, message) -Steve
Re: Alias delegates and @nogc
On Wed, 18 Feb 2015 18:13:58 +, ketmar wrote: it doesn't really cost *that* much (especially if you'll remember that DMD optimiser is far from... well, optimal ;-) i mean that there are alot of other code that isn't optimal for speed, so delegate call is rarely an issue. signature.asc Description: PGP signature
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 17:55:49 UTC, deadalnix wrote: Which is true, but would be as true without the horrible mention. Adjective do not constitute arguments. And your nonsensical point is?
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 09:04:38 UTC, Matthias Bentrup
wrote:
Windows SEH maintains a per-thread linked list of exception
handlers, but the C++ runtime seems to install only one handler
at the start of every function and resorts to lookup tables if
there are multiply try{}s in the function.
If you want to avoid lookup tables, you can of course
add/remove catchers dynamically whenever you enter/leave a try
block, that would add a small cost to every try, but avoids the
(larger) table lookup cost on the catch.
You want to do this as C++ introduce a ton of implicit finally
blocks for destructors. If you would setup one everytime you need
one, you would trash performance in the fast path.
Re: Thanks to p0nce for a nicer DConf logo!
On Sunday, 18 January 2015 at 19:39:38 UTC, Andrei Alexandrescu wrote: Take a look: http://dconf.org/2015/index.html. PR: https://github.com/D-Programming-Language/dconf.org/pull/37. -- Andrei Is thhere a higher res version out there?
Re: D and GPGPU
On Wednesday, 18 February 2015 at 15:15:21 UTC, Russel Winder wrote: The issue is to create a GPGPU kernel (usually C code with bizarre data structures and calling conventions) set it running and then pipe data in and collect data out – currently very slow but the next generation of Intel chips will fix this (*). And then there is the OpenCL/CUDA debate. Personally I think OpenCL, for all it's deficiencies, as it is vendor neutral. CUDA binds you to NVIDIA. Anyway there is an NVIDIA back end for OpenCL. With a system like PyOpenCL, the infrastructure data and process handling is abstracted, but you still have to write the kernels in C. They really ought to do a Python DSL for that, but… So with D can we write D kernels and have them compiled and loaded using a combination of CTFE, D → C translation, C ompiler call, and other magic? I'd like to about the kernel languages (having done both OpenCL and CUDA). A big speed-up factor is the multiple level of parallelism exposed in OpenCL C and CUDA C: - contect parallelism (eg. several GPU) - command parallelism (based on a future model) - block parallelism - warp/sub-block parallelism - in each sub-block, N threads (typically 32 or 64) All of that supported by appropriate barrier semantics. Typical C-like code only has threads as parallelism and a less complex cache. Also most algorithms don't translate all that well to SIMD threads working in lockstep. Example: instead of looping on that 2D image and perform an horizontal blur on 15 pixels, instead perform this operation on 32x16 blocks simultaneously, while caching stuff in block-local memory. It is much like an auto-vectorization problem and auto-vectorization is hard.
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote: From my POV best proposal from last lengthy discussion was to enable reference-counted non-gc-heap Exceptions. But that needs a language change because RefCounted!T is a struct and thus neither can be thrown nor can be part of Throwable class hierarchy. This is not satisfactory. First there is no safe way to refcount right now. Second, this has all kind of implication for the GC to scan the heap and so on. Finally this do not solve the type qualifier problem. I don't think a language change to do this pay for itself. i understand the appeal, as this is probably simpler to implement than the alternative, but that is really building technical debt. Any concept that implies that exceptions an be deallocated in `catch` block is absolutely unacceptable because it conflicts with exception propagation from fibers - a very important piece of functionality. Exception propagate the same way between thread, which is even worse :)
Re: Botan Crypto and TLS for D
On 2/18/15 9:32 AM, Etienne Cimon wrote: On 2015-02-18 11:41, Andrei Alexandrescu wrote: I'd love to add libasync to Phobos! -- Andrei Even as I add this as a dependency? : https://github.com/etcimon/memutils Instead of a single ScopedFiberPool, I intend to have ScopedPools with one stack in fiber, another in thread, and using the GC as a fallback. You can find a code example of the idea here: https://github.com/rejectedsoftware/vibe.d/issues/978#issuecomment-73819358 This is integration tactics that will need to be resolved. I don't see them as showstoppers. -- Andrei
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 18:43:49 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 18 February 2015 at 17:55:49 UTC, deadalnix wrote: Which is true, but would be as true without the horrible mention. Adjective do not constitute arguments. And your nonsensical point is? That you have no idea how to argue, and rely on sticking negative adjective close to things you don't like in hope that you'll fool someone. This post I'm answering to is more evidence of that. That's the last answer you'll get from me until you make any valuable argument.
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 18:59:03 UTC, deadalnix wrote: That's the last answer you'll get from me until you make any valuable argument. Excellent! I hope you keep your promise.
Re: Alias delegates and @nogc
ketmar wrote: On Wed, 18 Feb 2015 19:09:50 +0300, Ivan Timokhin wrote: Is there any way to pass a delegate that: 1. avoids indirect calls (like alias); 2. does not allocate (like scope delegate); 3. captures local variables? i don't think that you can do it. but what is wrong with delegate version? it doesn't really cost *that* much (especially if you'll remember that DMD optimiser is far from... well, optimal ;-), and if you really doing something where indirect function call matters, you'd better use mixins anyway. Thank you for the answer, I suspected as much.
Re: Alias delegates and @nogc
On 2/18/15 11:09 AM, Ivan Timokhin wrote:
With dmd 2.066.1, this compiles:
void bar(scope int delegate() a) @nogc {}
void foo(int x) @nogc
{
bar(() = x);
}
but this doesn't:
void bar(alias a)() {}
void foo(int x) @nogc
{
bar!(() = x)();
}
Fails with
Error: function test.foo @nogc function allocates a closure with the GC
Is there any way to pass a delegate that:
1. avoids indirect calls (like alias);
2. does not allocate (like scope delegate);
3. captures local variables?
Building on ketmar's point, I think you should not worry about tricking
the compiler into avoiding indirect calls. The compiler could and should
avoid indirect calls and GC closures when it can do so. In particular,
it should be able to inline bar, and (I assume in a full version of the
code) any uses of the delegate.
But it just doesn't yet.
-Steve
Re: Botan Crypto and TLS for D
On Windows, both x64 and x86 builds return a corrupt symbol table when building with debug symbols, and x64 doesn't work in release. For now I can build release/x86 only (although I get some unrelated bugs). I'm not sure but it seems like a problem with DMD for which I could use some help :-p
GC deadlocks on linux
I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Adding core.memory.GC.disable; to main causes the application to work correctly (and quickly till it runs out of memory :D ) I am running in a vagrant VM for test, but this should not be the issue. I am developing this for a future product so I wont have control over the environment that it runs in. I am not sure how to debug or work around this issue. My boss is a little concerned that I am using D but does think its cool. I really want to make this stable and get D in to one of our products, if not I will have to switch to C++ or even worse JAVA! Any help would be appreciated. -Byron System: DMD 2.066.1 Linux vagrant-ubuntu-precise-64 3.2.0-76-virtual #111-Ubuntu SMP Tue Jan 13 22:3 3:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION=Ubuntu 12.04.5 LTS NAME=Ubuntu VERSION=12.04.5 LTS, Precise Pangolin ID=ubuntu ID_LIKE=debian PRETTY_NAME=Ubuntu precise (12.04.5 LTS) VERSION_ID=12.04
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 18:02:14 UTC, Jonathan Marler wrote: On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote: From my POV best proposal from last lengthy discussion was to enable reference-counted non-gc-heap Exceptions. But that needs a language change because RefCounted!T is a struct and thus neither can be thrown nor can be part of Throwable class hierarchy. Any concept that implies that exceptions an be deallocated in `catch` block is absolutely unacceptable because it conflicts with exception propagation from fibers - a very important piece of functionality. RefCounted Exceptions would work quite nicely. You are right that It will require work on the language to support them but I like that solution. It will likely trigger whole load of other issues being totally new language concept but so far I am not aware of any better proposal. Of course to truly address @nogc you need also some sort of object pool for exceptions instances where those get returned upon release - otherwise it would simply move allocations from GC heap to plain heap. Which you can do already and does not really fix the problem. But that is a relatively simple library solution that can be built if reference counted exception become reality. If you don't mind, could you explain why cleaning up exception in the catch block would break exception propogation from fibers. Are you saying that if you throw inside a catch block and save a reference to the exception (in the new exceptions next field), that it will create a dangling pointer? Imagine application like vibe.d which uses fibers to imitate blocking API for async operations (we have something similar in Sociomantic projects too). Callbacks execute in the context of event loop but if any of those throws you want exception trace to point to original blocking call that registered callback. Right now doing this is relatively simple. You catch all exception in callbacks and store exception instance in relevant fiber-local data. Upon resuming that fiber it checks if there are any pending exceptions and re-throws if there is one. There are probably more tricky details but basic principle should be like this.
Re: quick-and-dirty minimalistic LISP engine
http://ketmar.no-ip.org/milf_for_the_masses.zip I'd like to see the source but on the other hand I'm so afraid to download this zip. :) Matheus.
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 21:05:10 UTC, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:55:56 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). By passing daemonize with the GC enabled is working.. going to dig into the signals and see if thats it. My guess is this is going to be related to forking, going to see if I can make a test case.
Re: Writing game engine in C++, considering switching to D
On 18 February 2015 at 20:48, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: GDC compiler is able to produce ARM code (and maybe LDC too, i don't know), GDC and LDC are able to produce any code. It's the runtime that may just need extra porting love. :) Iain.
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 21:21:11 UTC, Byron Heads wrote: On Wednesday, 18 February 2015 at 21:05:10 UTC, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:55:56 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). By passing daemonize with the GC enabled is working.. going to dig into the signals and see if thats it. My guess is this is going to be related to forking, going to see if I can make a test case. Might be related: https://issues.dlang.org/show_bug.cgi?id=6846
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 09:04:38 UTC, Matthias Bentrup wrote: If you want to avoid lookup tables, you can of course add/remove catchers dynamically whenever you enter/leave a try block, that would add a small cost to every try, but avoids the (larger) table lookup cost on the catch. There are many ways to get better performance than the current regime, both dynamic and static approaches, with little execution costs, but since most C++ programs don't rely on exceptions where speed matters there is little incentive to improve considering the complications in the backend. So I don't expect the C++ crowd to do anything about it. As a result C++ programmers that need speed can keep pretending exceptions don't exist, and if you don't need speed, why are you using C++? :-). Thus status quo persists and nothing interesting happens. D has made C/C++ compatibility a goal... so nothing is going to happen with D either... In most programs the possible call trees at a given point are quite limited, like a regular expression, so with whole program optimization you only need to special case catch blocks where the program may stop unwinding. I.e. you could detect which of the possible call trees you are in and unwind multiple stack frames from the same code location. If only a few functions can call you, you most certainly don't need to look up anything, right? If the compiler is allowed to move beyond the peephole separate compilation viewpoint...
Writing game engine in C++, considering switching to D
Hi, I have been working on a neat little game engine in C++ for the past year or so, and while C++ has served me well in the past, there are some points where its just awful to write. While I certainly can't call myself a master of C++, there's very little about the language that I am not familiar with, and I'd like to try something new. Since I am writing this engine just for fun and experience and C++ game engines have been done to death, a D game engine would make for an interesting project as well as providing great experience with system/application oriented programming. One of the main differences it seems between D and C++ is that the D compiler actually tries to be your friend by avoiding all the header/preprocessor/forward-declaration madness. I actually don't mind the syntax of C++ for the most part, but there are some cases where it just wants to make you tear your eyes out so you don't have to look at it anymore (ie, the '.template MemberNameT()' syntax for calling dependant member functions on templated variables. I understand why its necessary, but its still ugly as hell. I also think that forward-declarations are hideous devil-spawn and have no reason to exist in 2015). I like that D has a garbage collector, because while I intend to utilize RAII heavily in lower-level portions of code, having a native garbage collector to handle higher-level aspects (ie gameplay) would be extremely helpful. That's not to say I don't have concerns about switching to D, and so I'm outlining them below: Pros: - Prettier code (this is actually a very big plus for me, I'm almost OCD about the cleanliness of my code) - Modules: Less frustration with the compiler, faster compile times - Larger standard library. I hate it when C++ people complain about non-utility features for the standard library. You don't see C# people whining about how much more productive they are for it. - Garbage collection. Garbage collection allows you to focus on algorithms, not management, so I don't understand why some people are so vehemntly opposed to it. Cons (I'm not very experienced with D so these may be inaccurate): - Not as easy to get up and running (I haven't gotten DMD to work with VisualD yet, even though they both appear to be set up correctly. There may be an easy fix, but it doesn't exactly inspire confidence). PHP may be an awful language, but you can't deny that its incredibly easy to get up and running on a web server - and there's a lot of appeal to that. - DLLs. C++ DLLs/SOs are pretty simple for the most part, and don't require your code to really know that it's being referenced through a DLL. I really don't want to have to write dllmain and .def files for my DLLs. - Portability (?) While I'm not currently targeting more exotic platforms like PS4 or XBone or Android or the iPhone or even asm.js, I would like to keep those options open. I don't know how portable D is towards more gated platforms like those, so if anyone can clarify on this I'd appreciate it. - Library support. This may become a non-issue, as Ds support of C libraries seems pretty solid, and it sounds like further support for C++ is coming. Anyway, if anyone here can give me advice on whether I should transition or not, I'd appreciate it. Thanks!
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 20:25:07 UTC, Dicebot wrote: Right now I don't care for full memory safety or type safety of any proposed solution. I will be glad to have any that actually works - and I have not heard of any idea that allows to do that without language changes. Your push for owned is also hardly relevant because exceptions are good examples of data with shared / non-determenistic ownership and thus won't benefit from it. I think it make sense to require that something thrown to be owned. That means ownership can be transferred from one thread to the other. That also mean that the compiler can free the exception when it goes out of scope, which is what is wanted for exception and @nogc to work together. The invalid operation in @nogc would become promoting owned to Tl/shared/immutable rather than not allocating at all. This has added benefit to allow for way more code to be @nogc, and in many cases transfers the GCness of something in the caller, which makes for @nogc compatible libraries that can be used in both @nogc and gc situation. If we are gonna add something in the language, it'd better be worth it.
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:41:12 UTC, Dicebot wrote: Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890 Dont think so $dpkg --get-selections | grep gdm doesn't return anything also running via ssh
Re: Writing game engine in C++, considering switching to D
On Wednesday, 18 February 2015 at 20:29:34 UTC, Will Cassella wrote: Hi, I have been working on a neat little game engine in C++ for the past year or so, and while C++ has served me well in the past, there are some points where its just awful to write. Maybe you should consider creating D-bindings for your C++ engine and write a small game for it in D before you start porting? Anyway, if anyone here can give me advice on whether I should transition or not, I'd appreciate it. If your goal is to have fun I suggest you write something in D rather than port existing code. Otherwise you most likely will end up with why is this hard in D rather than this is much more fun in D.
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) signature.asc Description: PGP signature
Re: Writing game engine in C++, considering switching to D
On Wed, 18 Feb 2015 20:29:33 +, Will Cassella wrote: Anyway, if anyone here can give me advice on whether I should transition or not, I'd appreciate it. do you really expecting the answer no, stay with C++ in newsgroup that is dedicated to D language? ;-) as for some of your answer... using DMD from command line is dead easy both on GNU/Linux and on windows. you may miss visual studio integration and debugging, though. me not. ;-) GNU/Linux (and FreeBSD) .so support seems to work good, we can even use libphobos as shared library. it's still not possible to use libphobos as separate DLL on windows, AFAIK. yet you can write self-contained DLLs; alas, they will not share GC (so you can't transfer dynamically allocated heap object from one DLL to another). GDC compiler is able to produce ARM code (and maybe LDC too, i don't know), and i don't know about druntime porting status. yet there is some work done, and i believe that we will have more of that. i don't think that DMD will support ARMs in nearest future, as it requires completely new codegen for that. so if you aiming at portability, you'd better test your code with LDC/GDC (which usually one version behind the current DMD). as for the answer... writing such thing in D will be fun. and many things may change in the future (full support for windows DLLs, better ARM/ android support, ownership and better controlled memory management, etc.). i think that D is at least worth trying. you can always fallback to better C++ mode and write the missing parts yourself (and this will be fun too). signature.asc Description: PGP signature
Re: GC deadlocks on linux
Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). signature.asc Description: PGP signature
Re: Plan for Exceptions and @nogc?
On Wednesday, 18 February 2015 at 18:26:34 UTC, deadalnix wrote: On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote: From my POV best proposal from last lengthy discussion was to enable reference-counted non-gc-heap Exceptions. But that needs a language change because RefCounted!T is a struct and thus neither can be thrown nor can be part of Throwable class hierarchy. This is not satisfactory. First there is no safe way to refcount right now. Second, this has all kind of implication for the GC to scan the heap and so on. Finally this do not solve the type qualifier problem. I don't think a language change to do this pay for itself. i understand the appeal, as this is probably simpler to implement than the alternative, but that is really building technical debt. Right now I don't care for full memory safety or type safety of any proposed solution. I will be glad to have any that actually works - and I have not heard of any idea that allows to do that without language changes. Your push for owned is also hardly relevant because exceptions are good examples of data with shared / non-determenistic ownership and thus won't benefit from it.
Re: Dividing D Module between multiple files
On Wednesday, 18 February 2015 at 07:34:13 UTC, Daniel Kozák wrote: On Wed, 18 Feb 2015 07:23:24 + Muahmmad Adel via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I have searched online and I found no way for dividing D Module between multiple files. You are not force to do so I do not see any trouble here. For eg. I have lots of file where I have only one class (similar to java concept). The problem with this approach is that you will end with ugly class names like mypackage.myclass.MyClass. I'm porting some C# code where I need the type name at runtime and I ended with a huge package.d file just to keep pretty names like mypackage.MyClass. Another way to trick the compiler is to mixin import all modules in the package.d file but you'll loose features like code completion in your editor.
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize p.s. and check if you don't disable signals. druntime uses SIGUSR1 to communicate with threads (even if you aren't using more that one thread in your code). it doesn't on windows though (there are no signals there ;- ), but your posix code can accidentally block/intercept the signals druntime uses for internal bookkeeping. signature.asc Description: PGP signature
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:55:56 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). By passing daemonize with the GC enabled is working.. going to dig into the signals and see if thats it.
Re: quick-and-dirty minimalistic LISP engine
On Wednesday, 18 February 2015 at 21:22:56 UTC, MattCoder wrote: http://ketmar.no-ip.org/milf_for_the_masses.zip I'd like to see the source but on the other hand I'm so afraid to download this zip. Yep, I got aliced on the first line...
Re: Writing game engine in C++, considering switching to D
On Wed, 18 Feb 2015 21:24:42 +, Iain Buclaw via Digitalmars-d wrote: On 18 February 2015 at 20:48, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: GDC compiler is able to produce ARM code (and maybe LDC too, i don't know), GDC and LDC are able to produce any code. It's the runtime that may just need extra porting love. :) ARM is at least tested... well, for some extent. ;-) signature.asc Description: PGP signature
Re: quick-and-dirty minimalistic LISP engine
On Wed, 18 Feb 2015 22:31:00 +, Ola Fosheim Grøstad wrote: On Wednesday, 18 February 2015 at 21:22:56 UTC, MattCoder wrote: http://ketmar.no-ip.org/milf_for_the_masses.zip I'd like to see the source but on the other hand I'm so afraid to download this zip. Yep, I got aliced on the first line... yet you're still alive, so at least it's not fatal. i've cleaned the code a little since publication, but i don't want to remove Alice traces again and again, so let's consider code cleanup as an exercise for the reader. i know that everybody loves textbooks where the most interesting part is left as an exercise. signature.asc Description: PGP signature
[Issue 13167] Link errors with std.variant
https://issues.dlang.org/show_bug.cgi?id=13167
growler...@gmail.com changed:
What|Removed |Added
CC||growler...@gmail.com
--- Comment #1 from growler...@gmail.com ---
I have the same problem with this example:
---
import std.variant;
void main()
{
Variant a = true;
}
---
/tmp/.rdmd-1000/rdmd-hack.d-C187E56C4E00B02558F23ECBE6067626/objs/hack.o: In
function
`_D3std7variant18__T8VariantNVmi32Z8VariantN14__T7handlerTbZ7handlerFNeE3std7variant18__T8VariantNVmi32Z8VariantN4OpIDPG32hPvZl':
hack.d:(.text._D3std7variant18__T8VariantNVmi32Z8VariantN14__T7handlerTbZ7handlerFNeE3std7variant18__T8VariantNVmi32Z8VariantN4OpIDPG32hPvZl+0x30d):
undefined reference to `_D3std4conv11__T2toTAyaZ9__T2toTbZ2toFbZAya'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Demangled
/tmp/.rdmd-1000/rdmd-hack.d-C187E56C4E00B02558F23ECBE6067626/objs/hack.o: In
function `@trusted long
std.variant.VariantN!(32uL).VariantN.handler!(bool).handler(std.variant.VariantN!(32uL).VariantN.OpID,
ubyte[32]*, void*)':
hack.d:(.text.@trusted long
std.variant.VariantN!(32uL).VariantN.handler!(bool).handler(std.variant.VariantN!(32uL).VariantN.OpID,
ubyte[32]*, void*)+0x30d): undefined reference to `immutable(char)[]
std.conv.to!(immutable(char)[]).to!(bool).to(bool)'
collect2: error: ld returned 1 exit status
--- errorlevel 1
--
[Issue 13167] Link errors with std.variant
https://issues.dlang.org/show_bug.cgi?id=13167
--- Comment #2 from growler...@gmail.com ---
Sorry, I just noticed the date on this bug.
I am using DMD 2.67-b2 on Arch linux x86-64
DMD 2.066.1 works
DMD 2.067-b2 fails with the linker error.
(In reply to growlercab from comment #1)
I have the same problem with this example:
---
import std.variant;
void main()
{
Variant a = true;
}
---
/tmp/.rdmd-1000/rdmd-hack.d-C187E56C4E00B02558F23ECBE6067626/objs/hack.o: In
function
`_D3std7variant18__T8VariantNVmi32Z8VariantN14__T7handlerTbZ7handlerFNeE3std7
variant18__T8VariantNVmi32Z8VariantN4OpIDPG32hPvZl':
hack.d:(.text.
_D3std7variant18__T8VariantNVmi32Z8VariantN14__T7handlerTbZ7handlerFNeE3std7v
ariant18__T8VariantNVmi32Z8VariantN4OpIDPG32hPvZl+0x30d): undefined
reference to `_D3std4conv11__T2toTAyaZ9__T2toTbZ2toFbZAya'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Demangled
/tmp/.rdmd-1000/rdmd-hack.d-C187E56C4E00B02558F23ECBE6067626/objs/hack.o: In
function `@trusted long
std.variant.VariantN!(32uL).VariantN.handler!(bool).handler(std.variant.
VariantN!(32uL).VariantN.OpID, ubyte[32]*, void*)':
hack.d:(.text.@trusted long
std.variant.VariantN!(32uL).VariantN.handler!(bool).handler(std.variant.
VariantN!(32uL).VariantN.OpID, ubyte[32]*, void*)+0x30d): undefined
reference to `immutable(char)[]
std.conv.to!(immutable(char)[]).to!(bool).to(bool)'
collect2: error: ld returned 1 exit status
--- errorlevel 1
--
Re: Is this a bug in dmd 2.067 for struct initializers?
On 02/18/2015 10:39 PM, stewarth wrote:
This works under dmd 2066.1 but fails under dmd 2.067-b2.
I don't know whether it is a bug.
struct B {
A* a;
In any case, that must be immutable(A)*.
}
static immutable B[] someB = [{a:someA[0]}, {a:someA[1]}];
I want it to initialize at runtime before main(). I don't
actually want any CTFE stuff here.
Then you need 'static this()' (or 'shared static this()'):
static immutable B[] someB;
static this() {
someB = [ B(someA[0]), B(someA[1]) ];
}
Note that I could not use the named member syntax because in my case the
compiler cannot know what the right-hand side expression is. However, it
is still possible with a temporary where the type is explicit as in your
case:
static this() {
immutable B[] tmp = [ {a:someA[0]}, {a:someA[1]} ];
someB = tmp;
}
Ali
Is this a bug in dmd 2.067 for struct initializers?
Hi All,
This works under dmd 2066.1 but fails under dmd 2.067-b2.
---
struct A {
int val;
}
static immutable A[] someA = [{val:1}, {val:2}];
struct B {
A* a;
}
static immutable B[] someB = [{a:someA[0]}, {a:someA[1]}];
void main()
{
writefln(a:%s, someA);
writefln(b:%s, someB);
}
---
Error under DMD 2.067-b2:
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '[A(1), A(2)][0]'
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '[A(1), A(2)][1]'
Is this a bug, or a deliberate change?
I'm thinking a bug because I want it to initialize at runtime
before main(). I don't actually want any CTFE stuff here.
Thanks,
stew
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: Writing game engine in C++, considering switching to D
On 19 February 2015 at 12:08, Will Cassella via Digitalmars-d digitalmars-d@puremagic.com wrote: Thanks for the replies, everyone! I think I'll try my hand at writing bindings for my existing game engine, as Grøstad suggested - that way I can gradually transition the codebase to D if I like what I see. I've used D alongside C++ code in games for a few years, professionally, and in my own toy projects, including on the console platforms you expressed a concern for. You might want to take a look at my engine + bindings: https://github.com/TurkeyMan/fuji/tree/master/dist/include/d2/fuji You can do some cool stuff in D that is impossible in C++. vertex.d for instance demonstrates some interesting opportunities to make the bindings far nicer in D, even though it's just a front-end for a C++ engine.
Re: Google Summer of Code - Again
On Tuesday, 17 February 2015 at 11:52:15 UTC, Russel Winder wrote: On Mon, 2015-02-16 at 21:20 +, CraigDillabaugh via Digitalmars-d wrote: […] I haven't yet heard from Martin on his Melange name. Do you mind me putting your name down as assistant administrator if by submission time I still haven't heard from Martin (tomorrow or Wednesday). I assume I will be able to fix that after the fact, but I can't even submit the proposal unless of I have an assistant name, and so far you are the only one signed up on Melange that I know of. That is fine. Consider me duly signed up for the role, albeit temporarily. Russel. Can you accept my invitation to be adminstrator (perhaps you received and email about this), but who knows, that is the most baffling registration process I've ever been a part of
Re: Thanks to p0nce for a nicer DConf logo!
On Wednesday, 18 February 2015 at 23:44:34 UTC, ponce wrote: On Wednesday, 18 February 2015 at 19:12:27 UTC, Israel wrote: On Sunday, 18 January 2015 at 19:39:38 UTC, Andrei Alexandrescu wrote: Take a look: http://dconf.org/2015/index.html. PR: https://github.com/D-Programming-Language/dconf.org/pull/37. -- Andrei Is thhere a higher res version out there? Indeed the logo disappeared from the webhosting link I uploaded it to. Here it is: https://github.com/D-Programming-Language/dconf.org/pull/42 Wow so the logo is literally programmed...I havnt messed with svg files since haskell. Thanks though.
Re: quick-and-dirty minimalistic LISP engine
On Wednesday, 18 February 2015 at 22:37:34 UTC, ketmar wrote: yet you're still alive, so at least it's not fatal I became one year older, but I feel invigorated after this Alice encounter! and again, so let's consider code cleanup as an exercise for the reader. That's quite ok. I enjoy just looking at D code by different authors to get a picture of how the language is used in real code. So thanks for sharing! i know that everybody loves textbooks where the most interesting part is left as an exercise. Yes, especially if you get that part on an exam later on...
Re: Google Summer of Code - Again
On Thursday, 19 February 2015 at 04:28:35 UTC, Craig Dillabaugh wrote: On Tuesday, 17 February 2015 at 11:52:15 UTC, Russel Winder wrote: On Mon, 2015-02-16 at 21:20 +, CraigDillabaugh via Digitalmars-d wrote: […] I haven't yet heard from Martin on his Melange name. Do you mind me putting your name down as assistant administrator if by submission time I still haven't heard from Martin (tomorrow or Wednesday). I assume I will be able to fix that after the fact, but I can't even submit the proposal unless of I have an assistant name, and so far you are the only one signed up on Melange that I know of. That is fine. Consider me duly signed up for the role, albeit temporarily. Russel. Can you accept my invitation to be adminstrator (perhaps you received and email about this), but who knows, that is the most baffling registration process I've ever been a part of Oh, so its official now - I think - I've submitted our orgnaizational proposal. I had to copy and paste my beautiful Latex document into a crappy web-form, I am so bitter now. There is still time to add an idea or two to the Idea's page though ... since I've seen some recent chatter on the forums about GSoC project ideas.
Alias delegates and @nogc
With dmd 2.066.1, this compiles:
void bar(scope int delegate() a) @nogc {}
void foo(int x) @nogc
{
bar(() = x);
}
but this doesn't:
void bar(alias a)() {}
void foo(int x) @nogc
{
bar!(() = x)();
}
Fails with
Error: function test.foo @nogc function allocates a closure with the GC
Is there any way to pass a delegate that:
1. avoids indirect calls (like alias);
2. does not allocate (like scope delegate);
3. captures local variables?
Re: contiguous ranges
On Wednesday, 18 February 2015 at 08:34:49 UTC, Vlad Levenfeld
wrote:
I would argue that the only operations which preserve
contiguity are slicing, concatenating and appending; r.retro,
r.stride, r.map!f, etc should yield a RandomAccessRange.
I don't think this is a deal breaker, as conceptually its akin
to losing random-accessiblity under a filtering or grouping.
Input ranges are ubiquitous, RandomAccessRanges are more rare,
and ContiguousRanges are rarer still. It stands to reason that
contiguity is unlikely to be preserved under a given
transformation.
No.The main strenght of the range api is its ability to preserve
range categories.The loss of range categories is a *price* we pay
for lazy evalutation,categories wich can be restored by .array
in exchange for the usual price for dynamic allocation.
This needs, however, a few more implementations that
motivate the concept.
The main use cases I had in mind was for optimized data
transfers and passing arguments to C APIs, and in this regard
the definition of ContiguousRange would need a bit of
refinement, maybe like so:
A ContiguousRange r of type R is a RandomAccessRange which
satisfies hasLValueElements and defines a member called ptr
which satisfies the following conditions:
1) *r.ptr == r[0] r.ptr == r[0]
2) for all 0 = i r.length, *(r.ptr + i) == r[i] r.ptr
+ i == r[i]
We could then have:
void load_data (R)(R r) {
static if (isContiguousRange!R)
auto ptr = r.ptr;
else {
auto cache = r.array;
auto ptr = cache.ptr;
}
some_C_lib_call (r.length, ptr);
}
and
void copy (R,S)(R r, S s) if (allSatisfy!(isContiguousRange,
R, S)) {
// type and length equality assertions
vectorized_blit (ElementType!R.sizeof, r.length r.ptr,
s.ptr);
}
---
You are on track when you say the main use case would be
optimized data transfer and comunication with C.However you are
describing ContiguousRange as
a type implicitly convertable to T[],wich I deem too
restrictive.Optimized data transfers don't care at all that the
bytes are in order,only that the data are in the slice you gave
them.
Instead a contiguous range is one wich satisfies the following
contract:
R r;
static assert(hasLValueElements!R !isInfinite!R);
void[]s=r.toContiguous;
foreach(ref i;r)assert(s.ptr=is.ptr+s.lenght);
This allow,for example,to say:
void copy(R)(R r1,R r2)if(isContiguousRange!R){
void[]s1=r1.toContiguous,s2=r2.toContiguous;
memcpy(s1.ptr,s2.ptr,min(s1.lenght,s2.lenght);
}
It even give us a contiguous BinaryHeap,simply by
struct BinaryHeap(Store){
...
private Store store;
@propriety void[]toContiguous()if(isContiguousRange!Store){
return store.toContiguous;
}
}
and this BinaryHeap will be copied using only 1 call to memcpy.
Extending the concept to multiple dimensions is thorny, but
then, I've found that the same is true for everything but
RandomAccessRanges.
My proposal allow simple extension to multiple dimension.
if r is a n-dimensional range,then then the following must hold
true:
void[]s=r.toContiguous;
foreach(i1;r)foreach(i2;i1)...foreach(in;inprev)
assert(s.ptr=ins.ptr+s.lenght);
On Tuesday, 17 February 2015 at 15:50:17 UTC, Andrei Alexandrescu
wrote:
for an array r, is r.retro contiguous or not?
I would say yes.In general,a good rule of thumb would be:this
range can be copied via memcpy?Then preserve contiguous-ness.
For funcion accepting ranges ia a bit more complicated:
If the function cares that r[i]==*(s+i) then it should accept
only T[]
else it should accept contiguous ranges.
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 18 February 2015 at 08:52:33 UTC, Kelly wrote: Hello Elie, I just pushed a small pull request for fromTypeTemplateSpecialization. I forgot to mention in the request that the changes allow bitset.d to be compiled and run again. Thanks for looking into this, I'll check your PR. With those changes all the examples compile and run again. There are still two errors when compiling vector.d. Clang errors when making the pch file. LDC2 still runs and produces a working binary anyways. Not sure what you are working on, but I can look at those errors if you like. Are these errors occurring when Clang generates the PCH or later in the semantic pass? There might be errors during the instantiation of member functions of class templates because Calypso tries to instantiate everything (whereas Clang instantiates them lazily), but it's no big deal, later they'll be made silent. BTW I just pushed support for function template instantiation. So lately thanks to a bit of free time there has been quite a lot of new features implemented: overloaded operators, function templates, and groundwork for class value types (they were added to the AST as a new semi-hackish kind of type, they make mapping any C++ type possible but they can't be used directly from D code yet). Operators should make std::map usable, so I'm going to resume testing further STL types.
Re: Packt is looking for someone to author a Learning D
Well, Word can diff and merge documents, though, it works with sharepoint, not vcs.
Re: Botan Crypto and TLS for D
On Wednesday, 18 February 2015 at 12:28:11 UTC, Etienne Cimon wrote: On 2015-02-18 07:17, Jacob Carlborg wrote: On 2015-02-18 02:14, Etienne Cimon wrote: My favorite part is: vibe.d projects now compiles the entire software stack into a fully-featured standalone executable without any license issues. Isn't libevent required? Not anymore. I also wrote libasync and a vibe.d driver for it https://github.com/etcimon/libasync And libasync is another amazing piece of work, we are using it in a product we are developing. I must also add that, IMHO, it's a strategic error not having something like that in the standard library, but well, I know... --- Paolo
Re: quick-and-dirty minimalistic LISP engine
Oh boy. the source is messy ...
Re: Botan Crypto and TLS for D
On 2015-02-18 07:17, Jacob Carlborg wrote: On 2015-02-18 02:14, Etienne Cimon wrote: My favorite part is: vibe.d projects now compiles the entire software stack into a fully-featured standalone executable without any license issues. Isn't libevent required? Not anymore. I also wrote libasync and a vibe.d driver for it https://github.com/etcimon/libasync
Re: Type-Strict Indexes: IndexedBy
On Tuesday, 17 February 2015 at 19:46:09 UTC, Nordlöw wrote: Superb! I'd like to see this getting into std.typecons. Having this in the language will attract (more) Ada programmers to D. Should I do PR for std.typecons.[iI]ndexedBy? I'm not familiar with Ada, and I don't immediately see what indexedBy is good for. So maybe gather some examples where it's beneficial, before going for Phobos.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 13:59:43 UTC, Nordlöw wrote:
On Wednesday, 18 February 2015 at 13:53:17 UTC, Tobias Pankrath
wrote:
All the data members except distMap have reference semantics.
I thought AAs had reference semantics.
Me too, but the indeed have value semantics. See for example:
unittest
{
string[int] x;
auto y = x;
x[0] = zero;
assert(x != y);
}
This makes usage of storing internal state in Ranges bug-prone.
Isn't there some way to store an AA in reference wrapper?
This would simplify my .save member.
Because y does not alias x, it's a null pointer like AA. This
class is clearly a reference type, but the assert holds as well.
class C { int i; }
void main()
{
C c1;
C c2 = c1;
c1 = new C(12);
assert(c1.i != c2.i);
}
Re: Problem with coupling shared object symbol visibility with protection
On Monday, 16 February 2015 at 20:19:27 UTC, Jacob Carlborg wrote: On 2015-02-16 10:40, Benjamin Thaut wrote: This is in fact not a breaking change because export is broken anyway. Due to bug 922 export can't be used in cross platform libraries. I haven't seen a single library on dub that uses export (most likely for exactly that reason). Most likely due to that the support for dynamic libraries is fairly new only works on Linux (?). And the way it currently works on Linux `export` is completely ignored at all - hard to break something that has never worked.
Re: Plan for Exceptions and @nogc?
On Monday, 16 February 2015 at 23:17:03 UTC, Jonathan Marler wrote: Is there a proposal for how D will support throwing Exceptions in @nogc code in the future? I've searched the forums and found different proposals that involve things like pre-allocated exceptions, non-gc heap allocated exceptions or even stack allocated exceptions. I don't want to debate the details of each solution, I'd just like to know if any of these proposals are deemed a good idea, or if any of them are currently being worked on. I personally think that using non-gc heap allocated exceptions in combination with the new scope semantics would be a great solution in many cases, but I don't know if there is any consensus or if this topic is just on the back-burner. Thanks. From my POV best proposal from last lengthy discussion was to enable reference-counted non-gc-heap Exceptions. But that needs a language change because RefCounted!T is a struct and thus neither can be thrown nor can be part of Throwable class hierarchy. Any concept that implies that exceptions an be deallocated in `catch` block is absolutely unacceptable because it conflicts with exception propagation from fibers - a very important piece of functionality.
Re: Botan Crypto and TLS for D
On 02/18/2015 02:14 AM, Etienne Cimon wrote: I'll be working on HTTP/2 with websocket-style full duplex communications Glad to hear that.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 14:07:01 UTC, Steven Schveighoffer wrote: But once initialized, it DOES have reference semantics: string[int] x; x[0] = zero; auto y = x; x[1] = one; assert(x == y); Ok, great! I always initialize distMap with firstNd in the DijkstraWalk.this so that avoids the problem then. Thanks alot!
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 14:07:01 UTC, Steven Schveighoffer wrote: An UNINITIALIZED AA has not yet been allocated, and so it's reference is null. What's reason for uninitialized AA not behaving in the same way as arrays do?
Re: Botan Crypto and TLS for D
On Wednesday, 18 February 2015 at 04:17:16 UTC, Rikki Cattermole wrote: On 18/02/2015 5:01 p.m., Etienne Cimon wrote: On 2015-02-17 20:54, Rikki Cattermole wrote: On 18/02/2015 10:00 a.m., Etienne wrote: I'd like to announce the first release of Botan, which implements all features of v1.11.10 in the C++ library. I gave special attention to properly translating it to correct D code. It only runs with DMD master for now, only tested on Linux x86 or x86_64, and it uses a custom allocator library called memutils which must be placed in ../ I'd also want to underline that Alexander Bothe from Mono-D put some special attention to making sure the IDE runs smoothely with Botan. All tests are passing at the time of this writing (which is thousands of tests for all algorithms, incl x509, pubkeys, tls and so on). I'll let the wiki/api docs/code talk for me, I'm off to writing an TLS driver for vibe.d now Have fun! I'm quite excited by this. I do hope however that we get an ssh library now. Maybe git + mercurial + svn as well. We could do so much with that! It looks like this library (using Botan C++) could simply be translated to D code: https://github.com/cdesjardins/ne7ssh The only problem I see is that it's licensed QPL. However, the maintainer is missing and I think the library is simple enough to use it as a guideline/reference (along with other RFCs and libraries) and re-write an ssh library from scratch to get something new and original out of it and possibly use a more open license I saw that, I was worried about the license as well. I'll ping Craig. Maybe there is still time for somebody to take it on for GSOC? Having another project, or two, wouldn't be a issue. I haven't submitted the proposal yet, and I don't think the Google folks will start looking at the idea's pages until early next week, so there is no issue as far as I see adding something as late as this weekend. Having said that I am really busy this week and have been having trouble finding the time simply to fill out the Melange form and submit the proposal, I will get it done, so no need to worry. However, if someone wants to add another idea to the ideas pages I am leaving that up to them! Please try to follow the exiting template as close as possible ... if someone ends up doing this. The following open-source licenses are approved, and I noticed QPL is on there: http://opensource.org/licenses/alphabetical Craig
Re: Botan Crypto and TLS for D
On Wednesday, 18 February 2015 at 04:17:16 UTC, Rikki Cattermole wrote: On 18/02/2015 5:01 p.m., Etienne Cimon wrote: On 2015-02-17 20:54, Rikki Cattermole wrote: On 18/02/2015 10:00 a.m., Etienne wrote: I'd like to announce the first release of Botan, which implements all features of v1.11.10 in the C++ library. I gave special attention to properly translating it to correct D code. It only runs with DMD master for now, only tested on Linux x86 or x86_64, and it uses a custom allocator library called memutils which must be placed in ../ I'd also want to underline that Alexander Bothe from Mono-D put some special attention to making sure the IDE runs smoothely with Botan. All tests are passing at the time of this writing (which is thousands of tests for all algorithms, incl x509, pubkeys, tls and so on). I'll let the wiki/api docs/code talk for me, I'm off to writing an TLS driver for vibe.d now Have fun! I'm quite excited by this. I do hope however that we get an ssh library now. Maybe git + mercurial + svn as well. We could do so much with that! It looks like this library (using Botan C++) could simply be translated to D code: https://github.com/cdesjardins/ne7ssh The only problem I see is that it's licensed QPL. However, the maintainer is missing and I think the library is simple enough to use it as a guideline/reference (along with other RFCs and libraries) and re-write an ssh library from scratch to get something new and original out of it and possibly use a more open license I saw that, I was worried about the license as well. I'll ping Craig. Maybe there is still time for somebody to take it on for GSOC? Having another project, or two, wouldn't be a issue. I haven't submitted the proposal yet, and I don't think the Google folks will start looking at the idea's pages until early next week, so there is no issue as far as I see adding something as late as this weekend. Having said that I am really busy this week and have been having trouble finding the time simply to fill out the Melange form and submit the proposal, I will get it done, so no need to worry. However, if someone wants to add another idea to the ideas pages I am leaving that up to them! Please try to follow the exiting template as close as possible ... if someone ends up doing this. The following open-source licenses are approved, and I noticed QPL is on there: http://opensource.org/licenses/alphabetical Craig
Re: quick-and-dirty minimalistic LISP engine
On Wed, 18 Feb 2015 11:56:51 +, Stefan Koch wrote: Oh boy. the source is messy ... you have been warned! ;-) it was actually created within several hours to add simple scripting to another project, and i have no plans to improve it. so i decided to make it public, in a hope that it might be useful for somebody, and to show how one shouldn't write D code. ;-) signature.asc Description: PGP signature
Re: Botan Crypto and TLS for D
On 2015-02-18 02:14, Etienne Cimon wrote: My favorite part is: vibe.d projects now compiles the entire software stack into a fully-featured standalone executable without any license issues. Isn't libevent required? -- /Jacob Carlborg
Re: Botan Crypto and TLS for D
On 2015-02-18 05:22, ketmar wrote: On Wed, 18 Feb 2015 06:35:08 +, Joakim wrote: accompanied by benchmarks of the C++ and D code it's better to keep silence. dmd was never very good in optimising code. ;-) Not really, most of the sensitive code is optimized via native instructions, the crypto algorithms should be all the same. If you count the seconds for the unit test to run, powermod (public key cryptography) was equal in debug mode. Didn't check release though, but debug was 11sec and GCC optimizes the C++ version to 3 seconds :-p The sensitive parts are AES-NI and GCM, where the processor does the encryption, and I handled with care those native instructions so that should be 600MB/s - 1GB/s regardless of the compiler As for the learning experience, I spent most of the time doing search replace from C to D types and names, writing utils/simd instructions (__m128i __m256i xmmintrins.h etc), writing memutils (~= STL) because I needed proper containers and allocators to work with.
Re: Type-Strict Indexes: IndexedBy
On Wednesday, 18 February 2015 at 12:44:22 UTC, anonymous wrote: Should I do PR for std.typecons.[iI]ndexedBy? I'm not familiar with Ada, and I don't immediately see what indexedBy is good for. So maybe gather some examples where it's beneficial, before going for Phobos. Ok, I have a use case in one my applications I'll bring up. Thanks for now.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 13:37:57 UTC, Nordlöw wrote: I've written a Dijkstra-style graph traversal range at https://github.com/nordlow/justd/blob/master/knet/traversal.d#L105 that needs to internally store the AA distance map in member variable distMap. 1. All the data members except distMap have reference semantics. I thought AAs had reference semantics. Therefore I've made my range a class instead of a struct. Is this the correct way to do it? Neither false nor necessary. You could use a struct just as well. 2. To make it a ForwardRange I've also add a save() member. For now I've hardcoded the single member that needs to be duped. Is this correct way of doing it? That's how I'd do it.
Bugzilla email queue jammed?
I just saw that an issue I'm subscribed to was commented on hours ago, but no email from Bugzilla yet. They usually arrive instantly. Maybe some gears got stuck on the server?
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 13:53:17 UTC, Tobias Pankrath
wrote:
All the data members except distMap have reference semantics.
I thought AAs had reference semantics.
Me too, but the indeed have value semantics. See for example:
unittest
{
string[int] x;
auto y = x;
x[0] = zero;
assert(x != y);
}
This makes usage of storing internal state in Ranges bug-prone.
Isn't there some way to store an AA in reference wrapper?
This would simplify my .save member.
Re: Reference or Value Semantics for Graph Traversal Range
On 2/18/15 8:59 AM, Nordlöw wrote:
On Wednesday, 18 February 2015 at 13:53:17 UTC, Tobias Pankrath wrote:
All the data members except distMap have reference semantics.
I thought AAs had reference semantics.
Me too, but the indeed have value semantics. See for example:
unittest
{
string[int] x;
auto y = x;
x[0] = zero;
assert(x != y);
}
This is a well known problem.
An UNINITIALIZED AA has not yet been allocated, and so it's reference is
null.
But once initialized, it DOES have reference semantics:
string[int] x;
x[0] = zero;
auto y = x;
x[1] = one;
assert(x == y);
And to anticipate your question, no there is no way (yet) to create an
empty but initialized AA.
-Steve
