function cannot access frame
cannot access frame of function
I declared a helper function outside a lambda that is passed to C.
The semantics are the same inside of the function as they are
outside as far as code goes.
How can I declare a function that essentially works inside the
lambda also without having to do any real rewriting?
e.g., if I could use a define
#define foo(a,b) a + b
would work great, that is all I really need, templates have the
same issue as functions though.
To make it work I used a mixin template, but that seems a bit
obtuse ;/
e.g.,
template put()
{
int foo(a,b) { return a + b; }
}
mixin put;
then I mixin it inside the lambda also. That way I have both
contexts covered, not bad but...
Re: DerelictGL3 reload crashes in 32 builds
On Sunday, 20 August 2017 at 19:29:55 UTC, Igor wrote: In 64 bit builds it works with both LDC and DMD but in 32 bit LDC version crashes and DMD release version crashes. Using LDC debug build I managed to find that it crashes after executing ret instruction from bindGLFunc in glloader. If someone wants to try it you can do it with this project: https://github.com/igor84/dngin. I was testing this from Visual Studio but dub 32 bit LDC build also crashed. Am I doing something wrong or is this some known DerelictGL3 or compiler issue? This is a known issue [1] that I'm currently trying to resolve. I hadn't yet tested it using free functions (the bug report uses context types), so this new information helps. [1] https://github.com/DerelictOrg/DerelictGL3/issues/56
Re: std.range.put vs R.put: Best practices?
On Sunday, 20 August 2017 at 18:08:27 UTC, Jon Degenhardt wrote: Documentation for std.range.put (https://dlang.org/phobos/std_range_primitives.html#.put) has the intriguing line: put should not be used "UFCS-style", e.g. r.put(e). Doing this may call R.put directly, by-passing any transformation feature provided by Range.put. put(r, e) is prefered. This raises the question of whether std.range.put is always preferred over calling an output range's 'put' method, or if there are times when calling an output range's 'put' method directly is preferred. Also, it seems an easy oversight to unintentionally call the wrong one. Does anyone have recommendations or best practice suggestions for which form to use and when? --Jon It's recommended to always use the utility function in std.range unless you are working with an output range that has a well known put implementation. The issue is that put can be implemented to take any number or type of arguments, but as long as it has an implementation with one parameter of the range's element type, then the utility function will do the right thing internally whether you pass multiple elements, a single element, an array... It's particularly useful in generic code where most ranges are used. But again, if you are working with a specific range type then you can do as you like. Also, when the output range is a dynamic array, UFCS with the utility function is fine. As for mitigating the risk of calling the wrong one, when you do so you'll either get a compile-time error because of a parameter mismatch or it will do the right thing. If there's another likely outcome, I'm unaware of it.
Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?
On Monday, 21 August 2017 at 02:17:57 UTC, crimaniak wrote: ... shared A a; ... Sorry, accidental delete, read this as shared A a = new shared(A);
Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?
On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:
And no, this isn't ideal, but the only semi-decent solution
that's been proposed that safely casts away shared for you is
synchronized classes, which Andrei describes in TDPL but have
never been implemented.
After reading this I did some experiment to understand the
situation better. I make a simple class and unittest:
// dmd sync1.d -unittest -main
unittest
{
import std.stdio;
synchronized
class A
{
private int a;
void inc()
{
++a;
}
int get(){ return a;}
}
shared A a;
for(int i=0; i<100; ++i)
a.inc();
writeln(a.get);
}
Oops! Deprecation: read-modify-write operations are not allowed
for shared variables. Use core.atomic.atomicOp!"+="(this.a, 1)
instead.
Why use atomic operations if the class already synchronized?
Well..
...
import core.atomic: atomicOp;
...
// ++a; // Deprecation: read-modify-write operations are not
allowed for shared variables. Use
core.atomic.atomicOp!"+="(this.a, 1) instead.
atomicOp!"+="(this.a, 1);
...
ok, works. But it works by the way as if synchronized just makes
all methods shared, but does not provide the object methods with
a mutex lock, as Java does. Am I right here? And what preventing
to implement it right, lack of manpower or some ideologic
problems?
std.format expand "%s"
I'm playing around with std.format and I'm trying to figure out if there is any way to identify what "%s" should expand to. So for instance: int x = 1; auto result = x.format!"%s"; I would know that result="1". I could run "1" through unformatValue and get back 1. I'm looking to see if there is a way to get back "%d": really a function would be like f(x, "%s") produces "%d". Is there anything like that in std.format?
Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?
On Thursday, 17 August 2017 at 13:09:29 UTC, Kagamin wrote: On Wednesday, 16 August 2017 at 23:15:10 UTC, crimaniak wrote: I wonder if it possible and usable to make some template to support this pattern, where we give mutex(es), shared object(s) and delegate to operate with objects as non-shared. https://dpaste.dzfl.pl/8b3b05c8ec0a like this? Not sure if it helps, don't forget that it's a casted shared object. Yes, something like this. In general, I thought about the possibility of using several shared objects in this block but then realized that everything can be reduced to the case of one object.
GtkD: New widget
Hey Mike, I bet you can answer this!
I'd like to extend a widget to add some functionality.
class MyBox : Box
{
protected GtkBox* gtkBox;
import std.typecons;
_gtk.Box Wrapped;
mixin Proxy!Wrapped;
public this(Box b)
{
this.gtkBox = b.getBoxStruct();
super(gtkBox, false);
}
}
Trying something like the above does extend the box, as far as
allowing one to replace it, I think(using the code);
auto b = new MyBox(W1);
auto p = W1.getParent();
auto c = cast(Box)W4;
c.remove(W1);
c.add(b);
So, W4 is the main boxx, W1 is the box inside the main box I
replaced with the new box b.
When running that code, nothing changes, which, assuming we are
actually using the new box, then that is fine.
But I'm pretty sure that gtk never has a clue about `MyBox`? I
say this because I'd like to simply modify the reported sizes of
the box.
A gtkBox is not the same as a gtk.Box.
It seems like the best I can do is use a gtk.Container and
inherit from that.
e.g.,
class FixableSizedBox : Container
{
protected GtkContainer* gtkContainer;
import std.typecons;
_gtk.Container Wrapped;
mixin Proxy!Wrapped;
public this(Container b)
{
this.gtkContainer = b.getContainerStruct();
super(gtkContainer, false);
}
}
But even the GtkD container doesn't seem to contain any code to
deal with handling the sizes.
All I'm really looking to do is set the size of a container to
whatever I want.
Re: GtkD: Build script
On Sunday, 20 August 2017 at 20:13:17 UTC, Mike Wey wrote: On 20-08-17 20:41, Johnson Jones wrote: I guess I see why now you did what you did! ;) .LIB pagesize exceeds 512 https://issues.dlang.org/show_bug.cgi?id=15418 Wanna take bets on how many *years* this takes to get fixed?!? That one happens when GtkD is build with debug symbols. The main library is build by package because optlink or omf doesn't support more that 32767 symbols in one object file, and i hit that limit. ;/ After all, who will ever need more than 32767 symbols? Is this a problem with the linker or the object format? Maybe both oplink and dmd could be upgraded to use an extended omf format that allows more symbols?
Re: Mixed up over mixins.
On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:
It's stuff like this which makes me very frustrated. Or
depressed because it demonstrates just how poor a programmer I
am:
string printStatement(string message) {
return `writeln("` ~ message ~ `");`;
}
void main()
{
// Mixins are for mixing in generated code into the source
code.
// The mixed in code may be generated as a template instance
// or a string.
mixin(printStatement("hello world"));
mixin(`writeln(` ~ `Hello` ~ `);` );
mixin("writeln(`World`);");
}
Compiling gives me the errors:
Error: undefined identifier Hello
To me, `writeln(` ~ `Hello` ~ `);` is a valid D string? Okay,
maybe a
string expression but a string nevertheless.
So, am I giving mixin more magical powers than it possesses?
Should we say that mixin needs to be given a "fully pre-formed
D compilable" string?
Thanks. especially to let me vent.
It's not difficult, it's just new. It's not that you are a poor
programmer, but you simply have not learned how to think about
mixins correctly. Stop whining about it and focus that energy on
working with them.
String mixins are very simple. It takes any string and inserts it
as code in to the program directly as if you typed it by hand.
What makes them useful is that you can build strings a compile
time and so essentially introduce compile time code generation.
e.g.,
L324: mixin("Hello World")
becomes
L324: Hello World
and so
mixin(N)
gets inserted as
N, as if you typed it in directly. (this is the important part. N
isn't inserted but the contents of N as a string.
What this is good for, is say you want to generate code based off
stuff at compile time, e.g., a configuration file. You can
generate valid D code using strings that load the configuration
file at compile time and do what you want with it.
e.g.,
enum config = import(myconfigfile);
config now contains, as a string, the contents of myconfigfile AT
COMPILE TIME. Normally we think of config as being a run time
variable, but it is simply a compile time variable(well, it can't
vary, unfortunately, the compile time processing is not a fully
integrated compile time compiler.
enum configCode = process(config);
let process be a function that takes config, extracts the data
from it and bundles it all up in new D code.
mixin(configCode);
Now mixes in that code direct in to the source as if we typed it.
e.g.,
enum classes = import("classNames");
string code;
foreach(n; classes.split(","))
code ~= "class "~n~";\n";
// at this point code should be something like "class X;\nclass
Y;" etc, but it depends on the file.
mixin(code);
has the same effect if we typed
class X;
class Y;
But the difference is that we used a file to extract the class
names and a string mixin that inserted the code. This way we
don't have to manually change the class names in our D file, we
just change the classNames file, which is probably autogenerated
anyways.
String mixins come in very handy when you have D code that can be
"generalized" (parameterized).
It's sort of the place holder concept: You have a D string like
"
if (alpha_1 > 0) { Alpha1(); }
if (alpha_2 > 0) { Alpha2();}
if (alpha_3 > 0) { Alpha3();}
if (alpha_4 > 0) { Alpha4();}
"
...
Obviously if you can simplify all that code it would be nice,
well you can!
for(int i = 0; i < N; i++)
mixin("if (alpha_"~i~" > 0) { Alpha"~i~"();}");
this will mix N of those lines with the proper mapping. I only
have to make one change rather than N.
You have to think of them as D code generators. Of course, you
don't have to use them to generate code, but they are insert,
foremost, in D code and will be interpreted by the D compiler.
mixin("string X = \"mixin string X = \""mixin string X =
\"""mixin string X = .);
is the same as
string X = \"mixin string X = \""mixin string X = \"""mixin
string X = .;
and, if we used enums(compile time object) instead of strings(run
time object), we could do
mixin(X); and it would mix in the next layer, which would redfine
X each time.
It's not difficult, just requires a different way to think about
them, as does anything that is unfamiliar.
Re: GtkD: Build script
On 20-08-17 20:41, Johnson Jones wrote: I guess I see why now you did what you did! ;) .LIB pagesize exceeds 512 https://issues.dlang.org/show_bug.cgi?id=15418 Wanna take bets on how many *years* this takes to get fixed?!? That one happens when GtkD is build with debug symbols. The main library is build by package because optlink or omf doesn't support more that 32767 symbols in one object file, and i hit that limit. -- Mike Wey
Re: Mixed up over mixins.
On 08/20/2017 12:27 PM, WhatMeWorry wrote:
> // Mixins are for mixing in generated code into the source code.
> // The mixed in code may be generated as a template instance
> // or a string.
Yes, it means that the string must be legal D code.
> mixin(`writeln(` ~ `Hello` ~ `);` );
Yes, that's a D string but the string itself is not legal D code because
it would be mixing in the following:
writeln(Hello);
The problem is, there is no Hello defined in the program.
You need to make sure that Hello is a string itself:
writeln("Hello");
So, you need to use the following mixin:
mixin(`writeln(` ~ `"Hello"` ~ `);` );
Ali
Mixed up over mixins.
It's stuff like this which makes me very frustrated. Or depressed
because it demonstrates just how poor a programmer I am:
string printStatement(string message) {
return `writeln("` ~ message ~ `");`;
}
void main()
{
// Mixins are for mixing in generated code into the source
code.
// The mixed in code may be generated as a template instance
// or a string.
mixin(printStatement("hello world"));
mixin(`writeln(` ~ `Hello` ~ `);` );
mixin("writeln(`World`);");
}
Compiling gives me the errors:
Error: undefined identifier Hello
To me, `writeln(` ~ `Hello` ~ `);` is a valid D string? Okay,
maybe a
string expression but a string nevertheless.
So, am I giving mixin more magical powers than it possesses?
Should we say that mixin needs to be given a "fully pre-formed D
compilable" string?
Thanks. especially to let me vent.
DerelictGL3 reload crashes in 32 builds
In 64 bit builds it works with both LDC and DMD but in 32 bit LDC version crashes and DMD release version crashes. Using LDC debug build I managed to find that it crashes after executing ret instruction from bindGLFunc in glloader. If someone wants to try it you can do it with this project: https://github.com/igor84/dngin. I was testing this from Visual Studio but dub 32 bit LDC build also crashed. Am I doing something wrong or is this some known DerelictGL3 or compiler issue?
Re: GtkD: Build script
I guess I see why now you did what you did! ;) .LIB pagesize exceeds 512 https://issues.dlang.org/show_bug.cgi?id=15418 Wanna take bets on how many *years* this takes to get fixed?!?
GtkD: Build script
I've modified the build script:
changed 2 things: 1. Builds for all archs. 2. Replaced the
specialized x86 build with the generic used for 64-bit. You were
building for each individual directory for some reason, I guess
for more granularity, but it produced a different result than the
64 build because it left out the root gtk dir, when I put some
package files in to help make it easier to deal with all the
modules.
It might be better to put the libs in their own unique
directories. I was just tired of having to build for each version
so I simplified it. Probably could use some output mentioning
what is going on, although it works well, so maybe not.
I assume for 2 you just did that for more control? The lib file
was quite a bit larger(I think it went from 30 megs to 50 or
something).
Maybe a script such as this could be added and called buildAll.
module Build;
import core.stdc.stdlib: exit;
import std.algorithm;
import std.array;
import std.file;
import std.getopt;
import std.path;
import std.process;
import std.stdio;
import std.string;
string dcflags;
string ldflags;
int main(string[] args)
{
version(Posix)
{
writeln("This build script is currently Windows only.");
return(1);
}
getopt(args, "dcflags", , "ldflags", );
args.popFront();
foreach ( arg; args )
{
if ( !["gtkd", "gtkdgl", "sv", "gstreamer", "vte", "peas",
"all"].canFind(arg) )
{
writefln("Unknown option: %s", arg);
return 1;
}
}
if ( args.length == 0 )
args = ["gtkd", "sv"];
if ( args.canFind("all") )
args = ["gtkd", "sv", "gstreamer", "peas"];
foreach ( arg; args )
{
switch ( arg )
{
case "gtkd":
build("generated\\gtkd", "gtkd");
break;
case "gtkdgl":
build("generated\\gtkdgl", "gtkdgl");
break;
case "sv":
build("generated\\sourceview", "gtkdsv");
break;
case "gstreamer":
build("generated\\gstreamer", "gstreamerd");
break;
case "peas":
build("generated\\peas", "peasd");
break;
default:
assert(false);
break;
}
}
return(0);
}
void build(string dir, string lib)
{
import std.algorithm;
foreach(i; [0,1,2])
switch(i)
{
// 64bit
case 1:
std.file.write("build.rf", format("-m64 -c -lib %s %s
-Igenerated/gtkd -of%sx64.lib %s ", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
default: goto case 0;
case 0:
std.file.write("build.rf", format("-m32 -c -lib %s %s
-Igenerated/gtkd -of%sx86.lib %s ", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
case 2:
std.file.write("build.rf", format("-m32mscoff -c -lib %s %s
-Igenerated/gtkd -of%sx86coff.lib %s", dcflags, ldflags, lib,
dFiles(dir)));
auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
}
std.file.remove("build.rf");
}
string dFiles(string sourceDir)
{
string files;
auto entries = dirEntries(sourceDir, SpanMode.breadth);
foreach ( DirEntry entry; entries )
{
if ( entry.isDir == false && entry.name.extension == ".d" )
{
files ~= entry.name ~ " ";
}
}
return files;
}
std.range.put vs R.put: Best practices?
Documentation for std.range.put (https://dlang.org/phobos/std_range_primitives.html#.put) has the intriguing line: put should not be used "UFCS-style", e.g. r.put(e). Doing this may call R.put directly, by-passing any transformation feature provided by Range.put. put(r, e) is prefered. This raises the question of whether std.range.put is always preferred over calling an output range's 'put' method, or if there are times when calling an output range's 'put' method directly is preferred. Also, it seems an easy oversight to unintentionally call the wrong one. Does anyone have recommendations or best practice suggestions for which form to use and when? --Jon
Re: Estimating free system resource at runtime
On Sunday, 20 August 2017 at 15:49:09 UTC, seany wrote: However, i cant find anything on google to tell me how to estimate system resource using D. for C++ and windowes, i could find some API-s Can e do this in D? You can just use those C APIs. I believe the GC does, unless I'm reading it wrong. https://github.com/dlang/druntime/blob/acd2c55095ec039be2a9c20a8891ee40e4a393c3/src/gc/os.d#L173-L175 https://github.com/dlang/druntime/blob/acd2c55095ec039be2a9c20a8891ee40e4a393c3/src/core/sys/windows/winbase.d#L1383-L1392
Estimating free system resource at runtime
Hi I have a system that has to deal with 30+GB files. They can't be loaded to the amount of memory I have. So my idea was to create a way to estimate available system RAM, and read a chunk from file which is 1/10 of size of available RAM, and process it as far as i can. If the read chunk is too small to meaningfully process, then i wait until resources are free. If i read a chunk with some trailing things at the end that cant be processed, then i trim it, and reset the seek position. However, i cant find anything on google to tell me how to estimate system resource using D. for C++ and windowes, i could find some API-s Can e do this in D?
Re: Using mixin templates for operator overloading.
On Sunday, 20 August 2017 at 12:46:59 UTC, Nicholas Wilson wrote: Did you try changing the `: "+"` constraints to `if` constraints? Yes. Yields the same result as this.
Re: Using mixin templates for operator overloading.
On Saturday, 19 August 2017 at 10:16:18 UTC, Balagopal Komarath wrote: Let us say I want to automatically define subtraction given that addition and negation are defined. I tried the following using mixin templates. If I simply mixin the template using "mixin sub;", then it gives the error [...] Did you try changing the `: "+"` constraints to `if` constraints?
Re: Using mixin templates for operator overloading.
On Saturday, 19 August 2017 at 10:16:18 UTC, Balagopal Komarath wrote: Let us say I want to automatically define subtraction given that addition and negation are defined. I tried the following using mixin templates... I assume there is no way to do this?
Re: real simple delegate question.
On Saturday, 19 August 2017 at 18:33:37 UTC, WhatMeWorry wrote: On Friday, 18 August 2017 at 20:39:38 UTC, angel wrote: On Friday, 18 August 2017 at 02:38:15 UTC, WhatMeForget wrote: [...] This actually appears correct ... The 1-st example: Each call to makeCalculator() increments a static (i.e. shared among all makeCalculator() instances) variable - context. In addition, makeCalculator() generates a random variable. Whereas the delegate merely captures these variables, and the displayed results reflect this. The 2-nd example: There is a single call to makeCalculator(). After this call, context == 1, randy == _apparently 2_. Now the delegate, as has already been said, merely captures these values, so consecutive calls do not change the result. Thanks. So, auto calculator = makeCalculator(); is the actual call of the delegate? "Delegate is function pointer with context" But what is ...calculator(0)); Or maybe another approach would be to ask, what type is the compiler replacing auto with. No ! The actual call to the delegate is calculator(0). But this delegate does not induce change on its context variables, so it is expectable that consecutive calls to calculator(0) produce the same results, isn't it ? makeCalculator(), while not a delegate, also has a context variable - "static int context" - this is an "old-school" context variable implemented by the means of static variable. Consecutive calls to makeCalculator() return delegates having different contexts, so each call to calculator(0) produces different results.
