Re: is function pointer least significant bit always zero ?
On 10/27/2018 09:16 PM, learnfirst1 wrote: I plan to use function pointer least significant bit to store some information. If there is no GC on my system, I think it will help the memory is well aligned. The question is all the function least significant bit is zero ? Most definitely. Related presentation: http://dconf.org/2016/talks/sechet.html Ali
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 04:23:27 UTC, DanielG wrote:
On Sunday, 28 October 2018 at 03:39:41 UTC, Nicholas Wilson
wrote:
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
Thank you for your response.
Can you elaborate on 'write struct...'? Is that special syntax?
Nope thats me not proofreading my posts properly, sorry.
I also checked to see if you meant "(manually re-write it
as...)", but updating the struct definition in the generated .d
header with field values doesn't seem to solve the __initZ
issue, either.
Hmm thats, odd unless there are other fields with initialisers
that are forcing its emission.
And redefining it in the client .d module just shadows the
header definition, so ...
Try not using the .di files at all. I've never had any use for
them personally. Wrapping a C library, all thats required is
definitions of the functions and types declared by the headers.
this can be done with a .d file.
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 03:39:41 UTC, Nicholas Wilson wrote:
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
Thank you for your response.
Can you elaborate on 'write struct...'? Is that special syntax? I
assumed so, but dmd doesn't like it. I also checked to see if you
meant "(manually re-write it as...)", but updating the struct
definition in the generated .d header with field values doesn't
seem to solve the __initZ issue, either. And redefining it in the
client .d module just shadows the header definition, so ...
is function pointer least significant bit always zero ?
I plan to use function pointer least significant bit to store some information. If there is no GC on my system, I think it will help the memory is well aligned. The question is all the function least significant bit is zero ?
Re: Dub Renaming source/app.d makes project a library
On Sunday, 28 October 2018 at 03:34:57 UTC, Neia Neutuladh wrote: targetType "executable" does it for me (dub 1.11.0). Can you post your full dub.sdl? I'm an idiot, I was in the wrong directory that does seem to work.
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 03:28:20 UTC, DanielG wrote:
I'm wrapping a C library which has a lot of structs defined,
and I keep running into issues where dmd complains that .init
isn't defined ("Symbol Undefined __xxx__initZ" etc).
I'm struggling to narrow it down to a simple example that
demonstrates it - I actually made something that's kind of
minimal, but it goes from working to breaking depending on
whether the file extension is .di or .d, for the file
containing the extern (C)'ed struct definitions. Also it seems
to depend (in the .di case) on whether the C structs use double
vs. int values for their fields. (int fields work with either
file extension)
That is because the default initialiser for double is double.nan
which is non-zero and therefore the default initialiser of a
struct containing a double will have a non-zero default
initialiser. This lives as a __xxx__initZ symbol somewhere
in your program.
The .di or .d is because in the case of .di the compiler assumes
the symbols exist somewhere already and it doesn't need to (and
can't because it would create duplicates) emit them to the object
files.
But simply changing the file extension in my real project, of
the header files translated by dstep, seems to have no effect.
In short, it seems that for certain C structs I cannot use them
as a field in a D struct even with a manually-specified default
value - I get link errors no matter what
(init/toHash/opEquals). How can I get around that?
Am I supposed to be doing something with C structs to avoid
these kinds of errors in my D code? I've searched the forum but
nothing really jumps out at me as relevant.
For the __initZ symbols
struct Foo {
double bar;
}
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
and have only zero initialiser for you structs, which means they
don't need to be stored.
the opEquals stems from the fact that for structs containing
floats equality comparison cannot be implemented with bitwise
compare.
The easiest solution is to just use .d for the extension, very
rarely are .di files useful.
Re: Dub Renaming source/app.d makes project a library
targetType "executable" does it for me (dub 1.11.0). Can you post your full dub.sdl?
link errors when using extern (C) structs
I'm wrapping a C library which has a lot of structs defined, and
I keep running into issues where dmd complains that .init isn't
defined ("Symbol Undefined __xxx__initZ" etc).
I'm struggling to narrow it down to a simple example that
demonstrates it - I actually made something that's kind of
minimal, but it goes from working to breaking depending on
whether the file extension is .di or .d, for the file containing
the extern (C)'ed struct definitions. Also it seems to depend (in
the .di case) on whether the C structs use double vs. int values
for their fields. (int fields work with either file extension)
But simply changing the file extension in my real project, of the
header files translated by dstep, seems to have no effect.
In short, it seems that for certain C structs I cannot use them
as a field in a D struct even with a manually-specified default
value - I get link errors no matter what (init/toHash/opEquals).
How can I get around that?
Am I supposed to be doing something with C structs to avoid these
kinds of errors in my D code? I've searched the forum but nothing
really jumps out at me as relevant.
Dub Renaming source/app.d makes project a library
So I have a project that is a simple dub app with source/ app.d $dub Performing "debug" build using /Library/D/dmd/bin/dmd for x86_64. foo ~master: building configuration "application"... Linking... Running ./foo Edit source/app.d to start your project. $mv source/app.d source/foo.d $dub Performing "debug" build using /Library/D/dmd/bin/dmd for x86_64. foo ~master: building configuration "library"... Target is a library. Skipping execution. How do I get it to continue to build in the application configuration by default with the renamed file? I've tried mainSourceFile "source/foo.d" targetType "application" targetType "executable" to no avail. Thanks Nic
Re: Variant of chunkBy that can lazily split a string on case-changes
On Saturday, 27 October 2018 at 16:54:59 UTC, Per Nordlöw wrote: that can group elements using a binary predicate being able to do to the following. Oops, turns out I already had this at https://github.com/nordlow/phobos-next/blob/721374f3815db41cc213b108f81ca13ea7b93721/src/slicing.d#L12 This is a less generic solution though with a unary predicate but it works in my case. Still looking for a more general solution.
Variant of chunkBy that can lazily split a string on case-changes
Have anybody implemented a lazy iteration algorithm similar to
https://dlang.org/phobos/std_algorithm_iteration.html#chunkBy
that can group elements using a binary predicate being able to do
to the following.
This example
import std.ascii : isUpper, isLower;
foreach (e; ["SomeCamelCaseName"].chunkByX!((a,b) =>
a.isUpper && b.isLower))
{
writeln(e);
}
shall print
Some
Camel
Case
Name
?
Re: Pegged: spaces
On Saturday, 27 October 2018 at 14:21:51 UTC, Michelle Long wrote: What would be really cool if one could have an autogrammar generator! Somehow it looks at text and figures out the grammar. Might require some human interaction but can figure out the rules that will generate the specific grammars. Maybe neural net could do it? Train it enough and it could be fairly accurate and a human just has to fix up small cases. e.g., get a few million lines of C++ source code, pass in to the generator and it pops out a grammar for it! Should be possible since it's usually 1 to 1(for peg grammars at least). Something like eclipse's xtext would be nice, parts of the grammar are attached to OOP features in the code.
Re: Pegged: spaces
On Friday, 26 October 2018 at 07:36:50 UTC, drug wrote: 25.10.2018 23:34, Michelle Long пишет: Ignores spaces: <- Doesn't: < Concatenates results: <~ Thank you for sharing your results! I got it backwards when posting: /* < (space arrow) consume spaces before, between and after elements <- <~ (squiggly arrow) concatenates the captures on the right-hand side of the arrow. <: (colon arrow) drops the entire rule result (useful to ignore comments, for example) <^ (keep arrow) that calls the 'keep' operator to all subelements in a rule. / binary operator - conditional or (Matches first rule, if fails then matches the next) | binary operator - Longest match alternation(matches the longest rule first) : Prefix that ignores match in rule but requires it to be valid. */ List is not complete, maybe I will update. What would be really cool if one could have an autogrammar generator! Somehow it looks at text and figures out the grammar. Might require some human interaction but can figure out the rules that will generate the specific grammars. Maybe neural net could do it? Train it enough and it could be fairly accurate and a human just has to fix up small cases. e.g., get a few million lines of C++ source code, pass in to the generator and it pops out a grammar for it! Should be possible since it's usually 1 to 1(for peg grammars at least).
