GStreamer issues.
I can't get the example to work(although slightly modified).
The installed version of GStreamer is 1.12.2
The file is: D:\temp\test.ogg
Loading
Setting to PLAYING.
Running.
XError: Could not demultiplex stream. dbug: gstoggdemux.c(4418):
gst_ogg_demux_find_chains ():
/GstPipeline:audio-player/GstOggDemux:ogg-parser:
can't get first chain
Actually I was getting a much worse error before ;/ I can't
remember it now.
The installed version of GStreamer is 1.12.2
The file is: D:\temp\test2.wav
Loading
Setting to PLAYING.
Running.
XError: Internal data stream error. dbug: gstwavparse.c(2249):
gst_wavparse_loop ():
/GstPipeline:audio-player/GstWavParse:wav-parser:
streaming stopped, reason not-linked (-1)
Basically all I did was change the sink:
sink = ElementFactory.make("autoaudiosink", "auto-output");
So it I could get past the error about alsa. I think the last
name doesn't matter?
I downloaded the gstreamer binaries from their site, had some
issues with a few of the dll's complaining about gxx errors, I
removed them(h264, soundtouch, tag).
For the wav I changed
//parser = ElementFactory.make("oggdemux", "ogg-parser");
//decoder = ElementFactory.make("vorbisdec", "vorbis-decoder");
parser = ElementFactory.make("wavparse", "wav-parser");
decoder = ElementFactory.make("audioconvert", "wav-decoder");
which, is all i could find on line, I don't know if it's right at
all.
Ultimately I want to be able to read somewhat arbitrary audio
formats(most common at least), get the raw channel data(samples
for each channel), play/pause/stop with good accuracy(no latency
or low latency(<20ms), possibly do some pitch shifting and basic
mixing(EQ, limiting, panning, etc), and eventually play some
videos.
Is GstreamerD going to be useful for this or so I look in to
using ffmpeg directly and do some of the stuff(e.g., eq) myself?
Thanks.
Re: GtkD: New widget
On Monday, 21 August 2017 at 20:54:04 UTC, Mike Wey wrote:
On 21-08-17 03:45, Johnson Jones wrote:
[...]
If you want gtk to know about the functions you override you
could use gtkd.Implement.ImplementCLass.
[...]
Thanks, I'll test it out when I get a chance. I was able to work
around the issue for now but I imagine I'll need the ability to
implement my own container in the future.
BTW, when I try to create a value I get an error about opCall
Value handleSize = new Value(0);
vs
Value handleSize = Value(0);
I'd rather not create a value on the heap when I only need it
locally.
Could you add a way to create the value with the right type to
Value?
Even static constructors would work(probably could templatize it).
Although, I'm not sure how much it matters since value itself
seems to allocate on the heap ;/
public this()
{
this(new GValue);
}
But it might help reduce some memory waste.
Re: Mixed up over mixins.
On Monday, 21 August 2017 at 07:34:23 UTC, WhatMeForget wrote:
On Sunday, 20 August 2017 at 22:50:40 UTC, Johnson Jones wrote:
On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:
[...]
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.
[...]
Thank you. You have rejuvenated my quest for mixin mastery :)
Just stick with it ;) Things will click. The more you trudge
through them and just try to immerse yourself in it the faster it
will happen. I use mixins all the time because they are a great
way to simplify code... although actually writing them can be a
pain because you can't debug them in any sane way.
Remember, that you will generally use string generation a ton
because that is mainly what you are working.
Sometimes, for complex tasks I might have to write a function
that I run at runtime like a normal program that takes in a
string and outputs it. This lets me debug properly. As long as
one doesn't use crazy io(even file IO is blocked ;/) the same
function can be run at compile time(CTFE).
This means
myfoo("asdfasdf");
will be ran at compile time, the reason is simply that the input
is constant, there are no side effects, and so the output can be
computed at compile time.
But the same function can be debugged if ran at runtime... and
remember, the output is a string, so you can just print it out,
no mixin is occuring at this point.
The idea is that you make sure the string output is going to be
the correct D code you want to mixin. It should look like normal
D code, because if you do a mixin on it, it has to be to compile.
Any syntax errors will be picked up and you'll be hunting them
down because D will give you an obtuse error rather than a
specific line number in the mixin(this is a severe issue with D
but no one seem to care). If you debugged at runtime, you will
get a line number where the error occurred, which is why you go
that route.
Once you've gotten your function written to do the code, you
simply wrap a mixin() around it, you might have to change a bit
of runtime to compile time stuff(file io to import) and then all
that string stuff that you generated becomes D code!
mixin("int i = 3"); <- bug
mixin("int i = 3;"); <- ok
same as
int i = 3;
useless example but sometimes it's helpful. Sometimes to get the
things working you have to use mixins of mixins:
mixin("mixin("~something~");");
or, take this example
auto alpha = "hello";
mixin("w"~"r"~"i"~"te(`"~alpha~"`);");
before the mixin we have
"w"~"r"~"i"~"te(`"~alpha~"`);"
which, when simplified is
"write(`"~alpha~"`);"
which, since alpha is a constant, we have
"write(`hello`);"
which, the mixin simply does
write(`hello`);
which is now D code.
A mixin, in a sense, just "unstringifies" it's argument and
inserts it directly in to the source code... it better be valid
code, which also means the string better be a valid string of D
code.
Re: GtkD: New widget
On 21-08-17 03:45, Johnson Jones wrote:
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.
If you want gtk to know about the functions you override you could use
gtkd.Implement.ImplementCLass.
It's only in master and not completely finished yet, but you could use
it to for example overrride the getPreferredHeight and getPreferredWidth
functions.
I'm not completely clear on what you want to do with the size so they
might not be the correct functions to override.
```
class MyBox : Box
{
import gtkd.Implement;
import gobject.c.functions : g_object_newv;
mixin ImplementClass!GtkBox;
this()
{
//TODO: sort out the constructor.
super(cast(GtkApplication*)g_object_newv(getType(), 0, null), true);
}
override public void getPreferredHeight(out int minimumHeight, out
int naturalHeight)
{
//Set minimumHeight and naturalHeight.
}
override public void getPreferredWidth(out int minimumWidth, out int
naturalWidth)
{
//Set minimumWidth and naturalWidth.
}
}
```
--
Mike Wey
Re: Mixed up over mixins.
On 08/21/2017 12:29 AM, WhatMeForget wrote: > Thanks. Don't know if you noticed, but i used some code from your book. > Hope you take that as a complement. I did notice that and thank you. Every time I see people struggle with code that originated from my half-witted examples, I actually feel guilty. :) Ali
Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?
On 8/16/17 11:23 AM, Steven Schveighoffer wrote: On 8/16/17 8:58 AM, Steven Schveighoffer wrote: However, I have found a better way to call postblit that involves the qualifiers than the way Variant currently does it. I'm going to submit a PR to fix these issues. https://github.com/dlang/phobos/pull/5694 This has been merged, so you should now be able to send shared types properly through send/receive on master dmd. Don't think it made it into 2.076 beta though. -Steve
Re: std.format expand "%s"
On 8/21/17 10:58 AM, jmh530 wrote: On Monday, 21 August 2017 at 13:57:01 UTC, Steven Schveighoffer wrote: Well, for most things, %s does not do the same thing as another specifier. It's only integers, which format the same as %d, and floating points, which format the same as %g. For all others, the format is specified as %s. I think what you really want is just isFloatingPoint or isIntegral. I'm pretty sure that isFloatingPoint/isIntegral is not what I need, but I'm also not sure if what I was asking for above is needed either. So I'll just drop it for now. What I mean is that %s goes to %d for isIntegral!(typeof(x)), and %s goes to %g for isFloatingPoint!(typeof(x)), and stays as %s for everything else. Given this, you could probably write the function you were looking for. -Steve
Re: std.format expand "%s"
On Monday, 21 August 2017 at 13:57:01 UTC, Steven Schveighoffer wrote: Well, for most things, %s does not do the same thing as another specifier. It's only integers, which format the same as %d, and floating points, which format the same as %g. For all others, the format is specified as %s. I think what you really want is just isFloatingPoint or isIntegral. -Steve I'm pretty sure that isFloatingPoint/isIntegral is not what I need, but I'm also not sure if what I was asking for above is needed either. So I'll just drop it for now.
Re: Folder Size
On Monday, 21 August 2017 at 08:57:52 UTC, Aravinda VK wrote:
On Saturday, 19 August 2017 at 14:19:39 UTC, Vino.B wrote:
[...]
Keep a variable to add the sizes of subdirs
auto dFiles = dirEntries(i, SpanMode.shallow).filter!(a =>
a.isDir && !globMatch(a.baseName, "*DND*")).array;
ulong subdirTotal = 0;
foreach (d; dFiles)
{
subdirTotal = 0;
auto SdFiles = dirEntries(d, SpanMode.depth).array;
foreach(f; SdFiles) {
subdirTotal += f.size;
}
writeln(d, "\t", subdirTotal);
}
--
Aravinda
http://aravindavk.in
Hi Aravinda,
Thank you for the idea, but i have to tweek my code toas below
to get the required output and now I am able to get the required
output
auto dFiles = dirEntries(i, SpanMode.shallow).filter!(a =>
a.isDir && !globMatch(a.baseName, "*DND*")).array;
foreach (d; dFiles)
{
auto SdFiles = dirEntries(d, SpanMode.depth).array;
//auto entry = SdFiles.front;
foreach (f; SdFiles)
{
subdirTotal += f.size;
}
ulong subdirTotalGB = (subdirTotal/1000/1000);
writefln("%-63s %s %s", d, subdirTotalGB, "
MB");
subdirTotal = 0;
}
From,
Vino.B
Re: Mixed up over mixins.
On 8/21/17 3:29 AM, WhatMeForget wrote:
On Sunday, 20 August 2017 at 19:41:14 UTC, Ali Çehreli wrote:
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"` ~ `);` );
Of course, why didn't I "see" that before. I should have slept on it and
tried again with fresh eyes. I'm keeping a "beginners journal" on code
generation. Maybe write a 101 introduction with lots of samples and
exercises.
When doing mixins, especially when the code to generate the mixin string
isn't a simple literal, a great thing to do is to use pragma(msg) to
show the actual string you are mixing in.
e.g.:
enum mixinstr = ...
pragma(msg, mixinstr);
mixin(mixinstr);
Often times, your error is obvious when you see it that way.
-Steve
Re: std.format expand "%s"
On 8/20/17 9:52 PM, jmh530 wrote: 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? Well, for most things, %s does not do the same thing as another specifier. It's only integers, which format the same as %d, and floating points, which format the same as %g. For all others, the format is specified as %s. I think what you really want is just isFloatingPoint or isIntegral. -Steve
Re: DerelictGL3 reload crashes in 32 builds
On Monday, 21 August 2017 at 02:40:59 UTC, Mike Parker wrote: 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 I'm unable to reproduce this locally using my little test app. It only crashes for me in 32-bit when using context objects. I also took your winmain.d module, modified it to compile with `dub --single`, then compiled and executed it with both the default architecture (-m32) and -m32mscoff (via dub's -ax86_mscoff command line argument). In both cases it compiled executed just fine. Have you tried to compile outside of VisualD?
Re: delegates that return void + lambdas
On 8/21/17 8:15 AM, Joshua Hodkinson wrote:
So I have run across the following issue while working with delegates
and lambdas,
---
struct Struct {
int prop;
}
alias Func = void delegate(ref Struct);
Func func = (ref s) => s.prop += 1;
---
with compiler error `Error: cannot return non-void from function`
I understand that the lambda syntax in this case would be short for
---
Func func = (ref s) { return s.prop += 1; };
---
But does this mean you can't have lambdas that return void?
Thanks
You can return void when your return type is void. When the return type
is void, you can't return something other than void.
i.e., this should work:
alias Func = int delegate(ref Struct);
Or this:
void foo();
// with your original Func definition
Func func = (ref s) => foo();
You can also do this:
Func func = (ref s) { s += 1; };
-Steve
delegates that return void + lambdas
So I have run across the following issue while working with
delegates and lambdas,
---
struct Struct {
int prop;
}
alias Func = void delegate(ref Struct);
Func func = (ref s) => s.prop += 1;
---
with compiler error `Error: cannot return non-void from function`
I understand that the lambda syntax in this case would be short
for
---
Func func = (ref s) { return s.prop += 1; };
---
But does this mean you can't have lambdas that return void?
Thanks
Re: dmd (v2.075.0): fully static linking: undefined reference to `__tls_get_addr'
On 2017-08-19 16:07, kdevel wrote:
test.d
---
void main ()
{
}
---
$ dmd -c test.d
$ cc -o test test.o -L/[...]/dmd2/linux/lib64 -lphobos2 -static
-lpthread -lrt
/[...]/dmd2/linux/lib64/libphobos2.a(sections_elf_shared_774_420.o): In
function `_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv':
src/rt/sections_elf_shared.d:(.text._D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv[_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv]+0x38):
undefined reference to `__tls_get_addr'
collect2: error: ld returned 1 exit status
Found that on the net but no solution:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Static_linking_on_Linux_with_dmd_or_gcc_74954.html
Any hints?
You can use LDC to statically link the binary.
--
/Jacob Carlborg
Re: std.range.put vs R.put: Best practices?
On Monday, 21 August 2017 at 05:58:01 UTC, Jonathan M Davis wrote: On Monday, August 21, 2017 02:34:23 Mike Parker via Digitalmars-d-learn wrote: 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? 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. To add to that, the free function put handles putting different character types to a range of characters (IIRC, it also handles putting entire strings as well), whereas a particular implementation of put probably doesn't. In principle, a specific range type could do everything that the free function does, but it's highly unlikely that it will. In general, it's really just better to use the free function put, and arguably, we should have used a different function name for the output ranges themselves with the idea that the free function would always be the one called, and it would call the special function that the output ranges defined. Unfortunately, however, that's not how it works. In general, IMHO, output ranges really weren't thought out well enough. It's more like they were added as a countepart to input ranges because Andrei felt like they needed to be there rather than having them be fully fleshed out on their own. The result is a basic idea that's very powerful but that suffers in the details and probably needs at least a minor redesign (e.g. the output API has no concept of an output range that's full). In any case, I'd just suggest that you never use put with UFCS. Unfortunately, if you're using UFCS enough, it becomes habit to just call the function as if it were a member function, which is then a problem when using output ranges, but we're kind of stuck at this point. On the bright side, it's really only likely to cause issues in generic code where the member function might work with your tests but not everything that's passed to it. In other cases, if what you're doing doesn't work with the member function, then the code won't compile, and you'll know to switch to using the free function. Mike, Jonathan - Thanks for the detailed responses! Yes, by habit I use UFCS, there is where potential for the wrong call comes from. I agree also that output ranges are very powerful in concept, but the details are not fully fleshed out at this point. A few enhancements could make it much more compelling. --Jon
Re: Folder Size
On Saturday, 19 August 2017 at 14:19:39 UTC, Vino.B wrote:
Hi All,
I have written a small program to find the size of folder's ,
but the output is not as expected, hence request your help and
advice on any techniques to reduce the run time of the program.
Requirement:
The script has to scan several file system
("C:\\Temp\\TEAM","C:\\Temp\\PROD_TEAM", "C:\\Temp\\BACKUP")
Display only the sub folder level 1 name whose name should not
contain *DND* and size
dirEntries(i, SpanMode.shallow).filter!(a => a.isDir &&
!globMatch(a.baseName, "*DND*"))
Eg: C:\Temp\TEAM\USER_BACKUP , C:\Temp\PROD_TEAM\PROD_BACKUP ,
C:\Temp\BACKUP\SUPPORT_BACKUP
Need the folder name and size of each folder under
C:\Temp\TEAM\USER_BACKUP , C:\Temp\PROD_TEAM\PROD_BACKUP ,
C:\Temp\BACKUP\SUPPORT_BACKUP
Program
import std.file: dirEntries, isFile, SpanMode;
import std.stdio: writeln;
import std.algorithm: filter;
import std.array: array;
import std.path;
auto AgedDirlst = [ "C:\\Temp\\TEAM\\USER_BACKUP" ,
"C:\\Temp\\PROD_TEAM\\PROD_BACKUP" ,
"C:\\Temp\\BACKUP\\SUPPORT_BACKUP" ];
void main ()
{
foreach (string i; AgedDirlst[0 .. $])
{
auto dFiles = dirEntries(i, SpanMode.shallow).filter!(a =>
a.isDir && !globMatch(a.baseName, "*DND*")).array;
foreach (d; dFiles)
{
auto SdFiles = dirEntries(d, SpanMode.depth).array;
foreach (f; SdFiles)
writeln(f.dirName, "\t", f.size);
}
}
writeln("*");
}
Output:
C:\Temp\TEAM\USER_BACKUP\DIR1 41129
C:\Temp\TEAM\USER_BACKUP\DIR1\dir3 68
C:\Temp\TEAM\USER_BACKUP\DIR1 0
C:\Temp\TEAM\USER_BACKUP\DIR2\dir4 3410
C:\Temp\TEAM\USER_BACKUP\DIR2\dir4 2277663
C:\Temp\TEAM\USER_BACKUP\DIR2 0
C:\Temp\TEAM\USER_BACKUP\DIR2 1156
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1 41129
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1\dir3 68
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1 0
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1\DND1 36590125
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1 0
C:\Temp\PROD_TEAM\PROD_BACKUP\dir2\dir4 3410
C:\Temp\PROD_TEAM\PROD_BACKUP\dir2 0
C:\Temp\PROD_TEAM\PROD_BACKUP\dir2 1156
C:\Temp\BACKUP\SUPPORT_BACKUP\dir1\DND1 36590125
C:\Temp\BACKUP\SUPPORT_BACKUP\dir1 0
C:\Temp\BACKUP\SUPPORT_BACKUP\dir2\DND2 1156
---
Required Output
---
C:\Temp\TEAM\USER_BACKUP\DIR1 41197
(41129+68)
C:\Temp\TEAM\USER_BACKUP\DIR2 2282229
(3410+2277663+1156)
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1 36631322
(41129+68+36590125)
C:\Temp\PROD_TEAM\PROD_BACKUP\dir2 4566 (3410+1156)
C:\Temp\BACKUP\SUPPORT_BACKUP\dir1 36590125
C:\Temp\BACKUP\SUPPORT_BACKUP\dir2 1156
From,
Vino.B
Keep a variable to add the sizes of subdirs
auto dFiles = dirEntries(i, SpanMode.shallow).filter!(a =>
a.isDir && !globMatch(a.baseName, "*DND*")).array;
ulong subdirTotal = 0;
foreach (d; dFiles)
{
subdirTotal = 0;
auto SdFiles = dirEntries(d, SpanMode.depth).array;
foreach(f; SdFiles) {
subdirTotal += f.size;
}
writeln(d, "\t", subdirTotal);
}
--
Aravinda
http://aravindavk.in
Re: Mixed up over mixins.
On Sunday, 20 August 2017 at 22:50:40 UTC, Johnson Jones wrote: On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote: [...] 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. [...] Thank you. You have rejuvenated my quest for mixin mastery :)
Re: Mixed up over mixins.
On Sunday, 20 August 2017 at 19:41:14 UTC, Ali Çehreli wrote:
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
Of course, why didn't I "see" that before. I should have slept on
it and tried again with fresh eyes. I'm keeping a "beginners
journal" on code generation. Maybe write a 101 introduction with
lots of samples and exercises.
Thanks. Don't know if you noticed, but i used some code from your
book. Hope you take that as a complement.
Re: std.range.put vs R.put: Best practices?
On Monday, August 21, 2017 02:34:23 Mike Parker via Digitalmars-d-learn wrote: > 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. To add to that, the free function put handles putting different character types to a range of characters (IIRC, it also handles putting entire strings as well), whereas a particular implementation of put probably doesn't. In principle, a specific range type could do everything that the free function does, but it's highly unlikely that it will. In general, it's really just better to use the free function put, and arguably, we should have used a different function name for the output ranges themselves with the idea that the free function would always be the one called, and it would call the special function that the output ranges defined. Unfortunately, however, that's not how it works. In general, IMHO, output ranges really weren't thought out well enough. It's more like they were added as a countepart to input ranges because Andrei felt like they needed to be there rather than having them be fully fleshed out on their own. The result is a basic idea that's very powerful but that suffers in the details and probably needs at least a minor redesign (e.g. the output API has no concept of an output range that's full). In any case, I'd just suggest that you never use put with UFCS. Unfortunately, if you're using UFCS enough, it becomes habit to just call the function as if it were a member function, which is then a problem when using output ranges, but we're kind of stuck at this point. On the bright side, it's really only likely to cause issues in generic code where the member function might work with your tests but not everything that's passed to it. In other cases, if what you're doing doesn't work with the member function, then the code won't compile, and you'll know to switch to using the free function. - Jonathan M Davis
