Re: Good repos to learn D

2020-09-19 Thread H. S. Teoh via Digitalmars-d-learn
On Sat, Sep 19, 2020 at 08:26:36AM +, Imperatorn via Digitalmars-d-learn 
wrote:
> What are some good examples of pretty large/medium size, good
> structured repos in D? I'm looking for examples to learn from
[...]

Phobos itself.  I have to say, it's the most readable programming
language standard library that I've come across. I've tried to read
glibc code before, and I will never ever do that again(!). Phobos, by
contrast, is a pleasure to read (except for a small number of dark
corners).


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn


Re: create and initialise array

2020-09-19 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 19 September 2020 at 21:53:34 UTC, mw wrote:

On Thursday, 20 June 2019 at 07:57:25 UTC, KnightMare wrote:




imo NaN is useless, weird and unusual coz integrals and 
pointers are "all bits zeroes" but float and chars are "all 
bits ones". WTF? its strange that bool.init is false in such 
case.
.init = "all zeroes" can be faster initialize any block of 
memory.



I have the same question, why float/double are init to NaN, 
instead of 0? as other post-C++ language does? e.g Java, C# ...


What's the reason for this design decision?


The default init values in D are intended to stand out if you're 
looking at a printf dump or a debugger. NaN for float double, and 
invalid UTF values for char/wchar/dchar were intentionally 
chosen. For the integrals, there are no invalid values, so we're 
stuck with 0.


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread Adam D. Ruppe via Digitalmars-d-learn

On Sunday, 20 September 2020 at 01:51:22 UTC, wjoe wrote:
Would even be more awesome if it provided a function which 
could be called from a custom main on top of the FancyMain.
I find e.g. custom parsing of command line arguments incredibly 
useful.


Yea, the version 2.0 stuff inside cgi.d does that. You can call 
`cgiMainImpl` from your own main thing (that's all the mixin does 
anyway) and disaggregate it as much as you want.


I was improving that this week when the baby decided to come, so 
the rest will be coming a little later. But on my copy right now 
you can even break up cgiMainImpl because its implementation is:


---
void requestHandler(Cgi cgi) {
   // if you call cgi.dispatcher in here, it does basically
   // what the old FancyMain would do, going to a class.
}

void main(string[] args) {
alias CustomCgi = Cgi; // just normal class w/o more 
custom

if(tryAddonServers(args))
return;

if(trySimulatedRequest!(requestHandler, CustomCgi)(args))
return;

RequestServer rs;
rs.listeningPort = 3000; // if you want to change default
rs.configureFromCommandLineArguments(args);
rs.handleRequests!(requestHandler, CustomCgi)(); // this 
may never return

}
---


But I haven't pushed this live yet. Probably will write about it 
in the blog next week or the week after depending on how 
everything else irl goes. Still not 100% happy with it, but a big 
goal with my version 2.0 implementation here is to make more 
pick-and-choose customization possible while still using the 
automation in the places you want that.


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread wjoe via Digitalmars-d-learn

On Sunday, 20 September 2020 at 00:36:30 UTC, Adam D. Ruppe wrote:

[...]
That's it - all the html and javascript are all auto-generated.



Amazing :)
Would even be more awesome if it provided a function which could 
be called from a custom main on top of the FancyMain.
I find e.g. custom parsing of command line arguments incredibly 
useful.


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread wjoe via Digitalmars-d-learn

On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:
I personally (and many others in the industry... judging by 
popularity of express (node.js) and the plentiful third-party 
libraries,..do prefer the router.get() design. Also having 
everything abstracted in a convenient and consistent way...is 
very desirable. vibe.d's web interface API is something I've 
always praised and thanks to how powerful D is compare to say 
JavaScript. Diet templates is also an example.


I'm not a professional web developer and I don't intend to become 
one.
My intention is to live a long and mentally healthy life and web 
development is a serious threat to that ;)


However that power is not tapped in enough (yet) to favour 
using D conveniently over node (js). And web developers are 
interested in getting things done (at least my kind of web 
devs) rather than getting it our way...or squeezing every bit 
of efficiency out of it. Part of why v8 is fast by default (for 
us).


But joking aside, I'm going to use D over Javascript any day of 
the week no questions asked.
And despite my constant bickering, vibe is a huge accomplishment 
and improvement over what I used in the past. So kudos.




Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread wjoe via Digitalmars-d-learn
On Saturday, 19 September 2020 at 19:27:40 UTC, Steven 
Schveighoffer wrote:

[...]
This used to be the expected way to set up vibe (using module 
constructors). And vibe would provide its own main function.


I *think* the idea was to allow registration of different 
handlers in their respective modules.


A reasonable decision if you assume that's the only thing you 
want to do.
Vibe and dub share this philosophy. The author(s) assumed those 
are the only use cases and nothing else flies.
Like for e.g. you can build a D application that uses a C library 
with D glue code and compile the files together in 1 go with GCC, 
maybe with LDC, too, but I haven't tried.

something like: gcc main.d dglue.d clib.c clib.h
But this doesn't work with dub, or at least it didn't work the 
last time I tried a year or so ago.

I'm not a fan of the "The one true way" philosophy.


[...]
I used Kai's book, and yeah, you have to do things the vibe 
way. But most web frameworks are that way I think.


I recommend getting the book if you plan on doing a lot with 
vibe.d


I forgot that I got it some time ago, never really got around to 
take a look however. Thanks for the reminder :)


Where vibe really shines are the diet templates and the web 
interface stuff. To not have to handle anything from forms, or 
query parameters, and just write normal D functions is really 
great. You can even do a lot of authentication and stuff using 
UDAs. It helps you write consistent web applications.


And I LOVE diet templates. So much less verbose than actual 
HTML. I have a hard time writing actual HTML now.


Those are the only reason why I didn't throw it out, yet. Maybe 
it will make up for some of the initial frustration :)


When you want to do stuff manually, I think it's not as well 
supported.


-Steve





Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:
Arsd cgi.d might be what you want if you want to it your way as 
its more low-level interface-wise.


Eh, it depends. My lib lets you do as much or as little as you 
want.


About ten years ago, I wrote a framework on top that 
automatically generates javascript/json interfaces as well as 
html form and output UI just given an ordinary D class. Had full 
interop with PHP too... all with no UDAs since they didn't exist 
yet!


I never really documented how to use it. Wrote a few examples on 
the forum but nothing formal. I kinda regret that; I've *still* 
never seen anyone else, anywhere, automate as much as it did.


old demo I posted in May 2011: 
http://arsdnet.net/cgi-bin/apidemo/javascript


I can't find the source to that anymore but it would be something 
like:


---
import arsd.web;

class CoolApi : WebApi {
   enum Color { red, green, etc }
   struct Person { int id; string first; string last; }

   Element getABox(Color c) {
 auto div = Element.make("div");
 div.style.color = to!string(c);
 return div;
   }

   int addSomeNumbers(int a, int b) { return a + b; }

   Person[] getPeople(int startingId) { return [Person(...)]; }
}
mixin FancyMain!CoolApi;
---

That's it - all the html and javascript are all auto-generated.


Nowadays I'm merging all those ideas into cgi.d and actually 
writing about it in my blog. There's a lot in my old 
implementation I didn't like but now that D's reflection is 
better than it was, I have techniques to make it even better.


My new dwidder website is the only public example of the new code 
so far 
https://github.com/adamdruppe/dupdates/blob/master/main.d#L157


Still a bunch more I'm slowly bringing together. D has unique 
strengths for web that javascript, ruby, and python can just 
*never* do and we should be pushing the edges to go as cool as we 
can.




Re: Building LDC runtime for a microcontroller

2020-09-19 Thread IGotD- via Digitalmars-d-learn

On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote:


I use D in an automotive environment (it controls parts of the 
powertrain, so yeah there are cars running around on D) on 
various types of ARM Cortex M CPUs, I think this will be the 
best way to extend D to those platforms.




Do I dare to ask what brand of cars that are running D code. 
Maybe you're supplier that sells products to several car brands.




Re: create and initialise array

2020-09-19 Thread mw via Digitalmars-d-learn

On Thursday, 20 June 2019 at 07:57:25 UTC, KnightMare wrote:

On Thursday, 20 June 2019 at 01:32:04 UTC, matheus wrote:



import std.stdio;
import std.array;

void main(){
auto s = uninitializedArray!(float[])(100);
s[] = 0.0f;
writeln(s[0]);
}


Even with this, user has to write two statement, why we can't 
just have:


  auto s = new float[100](0);



another version:
auto arr = new double[ 10 ];
writeln( arr[5] ); // NaN
arr.length += 10;
writeln( arr[15] ); // NaN

imo NaN is useless, weird and unusual coz integrals and 
pointers are "all bits zeroes" but float and chars are "all 
bits ones". WTF? its strange that bool.init is false in such 
case.
.init = "all zeroes" can be faster initialize any block of 
memory.



I have the same question, why float/double are init to NaN, 
instead of 0? as other post-C++ language does? e.g Java, C# ...


What's the reason for this design decision?



Re: Building LDC runtime for a microcontroller

2020-09-19 Thread aberba via Digitalmars-d-learn

On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote:

On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote:

[...]


I use D in an automotive environment (it controls parts of the 
powertrain, so yeah there are cars running around on D) on 
various types of ARM Cortex M CPUs, I think this will be the 
best way to extend D to those platforms.


Wow. Happy to hear this.

Do you attend our monthly D online meetups?



The existing runtime is PC-oriented. Embedded stuff doesn't 
need a GC or some of the more advanced features, but having 
things like classes, interfaces, dynamic arrays would make the 
development workload a lot easier.

+1




A lot of embedded stuff is done with RTOSs now that provide 
memory management and threading support, so having a flexible 
lightweight runtime with a generic backend (mem allocation, 
threads) that I can hook to the RTOS' libraries would be great.


I think Ali was also working on or at least talked about that OS 
(if I remember correctly) at Dconf, right?


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread aberba via Digitalmars-d-learn

On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:

On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:

Are there other frameworks besides vibe that can do what I 
want?


Personally I use vibe.d for basic side projects. Looking to use 
it more going forward. But that's how I see it.


This is my personal collection of D web development packages. Let 
me know if I'm missing something.


https://gist.github.com/aberba/dcaf9102b35205080ad99a2af2c21142



Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread aberba via Digitalmars-d-learn

On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:

Are there other frameworks besides vibe that can do what I 
want?


Just FYI, there is also:

https://code.dlang.org/packages/hunt-framework


I never used myself, you need to investigate.


Yeah, I'm aware of hunt too. Its like laravel in php whilst 
vibe.d feels more like express in nodejs. Infact I believe Sonke 
wrote vibe.d after using express or similar framework by design.



And yes, almost all frameworks work in a certain way. Arsd cgi.d 
might be what you want if you want to it your way as its more 
low-level interface-wise.


I personally (and many others in the industry... judging by 
popularity of express (node.js) and the plentiful third-party 
libraries,..do prefer the router.get() design. Also having 
everything abstracted in a convenient and consistent way...is 
very desirable. vibe.d's web interface API is something I've 
always praised and thanks to how powerful D is compare to say 
JavaScript. Diet templates is also an example.


However that power is not tapped in enough (yet) to favour using 
D conveniently over node (js). And web developers are interested 
in getting things done (at least my kind of web devs) rather than 
getting it our way...or squeezing every bit of efficiency out of 
it. Part of why v8 is fast by default (for us).


Unike express (which is a thing layer with interface for 
third-parties to hook in and extend with libs), vibe.d became a 
monolith with everything included... making it harder to maintain 
and extend in other ways. Plus too much hard-coding by default 
currently. Unfortunately Sonke doesn't work on it like he used 
to...and its quite an huge accomplishment...the work he's done 
for D.



I wish vibe.d could be positioned and sponsored officially or by 
community cus its the killer app.


Staying lean and being extensible will open up for more 
innovation around it. Eg. a form handler for files library that 
works like how Ikod suggested...a customizable stream.



Unless you're doing usual routing and database things, using 
vibe.d for a full stack projects can lead to a dead end unless 
you're positioned to write your own stuff to supplement. Of 
course its only a matter of time before this change for the good.


Personally I use vibe.d for basic side projects. Looking to use 
it more going forward. But that's how I see it.


Re: Escape this in pure members

2020-09-19 Thread Per Nordlöw via Digitalmars-d-learn
On Saturday, 19 September 2020 at 18:48:31 UTC, Jacob Carlborg 
wrote:

A nested class seems to be able to escape the `this` reference:


Ahh, thanks.

I just realized that it can escape into other parameters without 
the `scope` qualifier?


This

class Bar
{
void bar(scope Bar b) @safe pure
{
b = this;
}
}

compiles but this

class Bar
{
scope void bar(scope Bar b) @safe pure
{
b = this; // Error: scope variable `this` assigned to `b` 
with longer lifetime

}
}

fails as

foo.d(6,11): Error: scope variable `this` assigned to `b` with 
longer lifetime


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread ikod via Digitalmars-d-learn
On Saturday, 19 September 2020 at 18:56:20 UTC, Steven 
Schveighoffer wrote:

On 9/19/20 7:15 AM, ikod wrote:

On Saturday, 19 September 2020 at 11:11:21 UTC, ikod wrote:

On Friday, 18 September 2020 at 13:13:16 UTC, wjoe wrote:


My preferable way to handle such thing is: convert incoming 
data into input range of immutable(ubyte)[] and let user to 
consume this range (and handle it as it wish - transform, 
store in memory as is, or dump to disk)


sorry, this looks exactly like it described in proposal (and 
this is how requests works).




You mean for each file, right? Yeah, that is the proposal,


If user uploads several files through single form then yes, for 
each file. Maybe handler should receive range of input ranges and 
handle each as necessary.



though it uses Vibe's io type (necessary I think).

-Steve





Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread Steven Schveighoffer via Digitalmars-d-learn

On 9/19/20 3:36 PM, IGotD- wrote:

On Saturday, 19 September 2020 at 19:27:40 UTC, Steven Schveighoffer wrote:


I used Kai's book, and yeah, you have to do things the vibe way. But 
most web frameworks are that way I think.




Do you have a reference to this book (web link, ISBN)?




Sure:

https://www.packtpub.com/product/d-web-development/9781785288890

It might be a bit dated, but most of the concepts are the same.

-Steve


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread IGotD- via Digitalmars-d-learn
On Saturday, 19 September 2020 at 19:27:40 UTC, Steven 
Schveighoffer wrote:


I used Kai's book, and yeah, you have to do things the vibe 
way. But most web frameworks are that way I think.




Do you have a reference to this book (web link, ISBN)?




Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread Steven Schveighoffer via Digitalmars-d-learn

On 9/19/20 6:59 AM, wjoe wrote:

Handling file uploads is one example, another is command line arguments.
The presumption here is there is vibe and there can only be vibe. It 
takes them from Runtime.args. Duh?
This didn't make sense to me until I saw example where the 
initialization of vibe was done in a module constructor.


This used to be the expected way to set up vibe (using module 
constructors). And vibe would provide its own main function.


I *think* the idea was to allow registration of different handlers in 
their respective modules.


Nowadays, you just run the setup wherever you want (I do everything in 
main).


By using vibe I feel like I need to bend myself like a snake and jump 
through the hoops of vibe's one way to do it. You save a lot of time 
here and there and then you lose half a day because of some stupid road 
block like the above.


I used Kai's book, and yeah, you have to do things the vibe way. But 
most web frameworks are that way I think.


I recommend getting the book if you plan on doing a lot with vibe.d

Where vibe really shines are the diet templates and the web interface 
stuff. To not have to handle anything from forms, or query parameters, 
and just write normal D functions is really great. You can even do a lot 
of authentication and stuff using UDAs. It helps you write consistent 
web applications.


And I LOVE diet templates. So much less verbose than actual HTML. I have 
a hard time writing actual HTML now.


When you want to do stuff manually, I think it's not as well supported.

-Steve


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread Steven Schveighoffer via Digitalmars-d-learn

On 9/19/20 7:15 AM, ikod wrote:

On Saturday, 19 September 2020 at 11:11:21 UTC, ikod wrote:

On Friday, 18 September 2020 at 13:13:16 UTC, wjoe wrote:
On Friday, 18 September 2020 at 12:58:29 UTC, Steven Schveighoffer 
wrote:

On 9/18/20 8:39 AM, Steven Schveighoffer wrote:
But again, solved with an enhancement that allows you to process 
the data in your code. I'll file the enhancement request for you, 
as I think it's a nice addition.


https://github.com/vibe-d/vibe.d/issues/2478



Awesome! Thanks a ton :)


My preferable way to handle such thing is: convert incoming data into 
input range of immutable(ubyte)[] and let user to consume this range 
(and handle it as it wish - transform, store in memory as is, or dump 
to disk)


sorry, this looks exactly like it described in proposal (and this is how 
requests works).




You mean for each file, right? Yeah, that is the proposal, though it 
uses Vibe's io type (necessary I think).


-Steve


Re: Question about linker errors when using slices

2020-09-19 Thread Steven Schveighoffer via Digitalmars-d-learn

On 9/18/20 10:45 PM, tspike wrote:

If you only compile platform.d, the linker will complain about 
“undefined references.” This is true when using dmd and gdc, though 
platform.d compiles just fine when using ldc. But the file only fails to 
compile when the “items” member of AppData is a slice; if “items” is an 
int* platform.d will compile.


The linker spits the following:

     platform.o:(.data._D22TypeInfo_S3app7AppData6__initZ+0x30): 
undefined reference to `_D3app7AppData9__xtoHashFNbNeKxSQBeQBdZm'
     platform.o:(.data._D22TypeInfo_S3app7AppData6__initZ+0x38): 
undefined reference to `_D3app7AppData11__xopEqualsFKxSQBdQBcKxQjZb'


I was just wondering if anyone knows if this behavior is expected or if 
this is a compiler bug. Thank you in advance for your time!


On one hand, I don't necessarily expect it. These are symbols that are 
used to build an appropriate TypeInfo instance.


I wouldn't expect it, because you aren't using TypeInfo anywhere.

However, it does happen quite a bit, because the conditions under which 
D generates or expects a generated TypeInfo are somewhat obscure and not 
documented. It's probably why LDC works and the others don't.


I hope Andrei's recent push to demystify TypeInfo stuff makes this a lot 
more tractable.


The answer is -- just build with all the files. The linker should throw 
out stuff that isn't needed.



PS: I hope this is the right sub-forum for asking this sort of question!


Of course!

-Steve


Re: Escape this in pure members

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn

On 2020-09-19 18:07, Per Nordlöw wrote:
If an aggregate member is pure but not scope when can it escape the 
`this` pointer?.


Only via return?


I'm not sure if returning the `this` pointer is considered escaping it. 
The caller already had access to it. Under the hood, the `this` pointer 
is just another argument passed to the function.



In the struct and class case?


A nested class seems to be able to escape the `this` reference:

class Foo
{
Bar b;

class Bar
{
void bar() pure
{
b = this;
}
}
}

--
/Jacob Carlborg


Re: Vibe.d

2020-09-19 Thread Andre Pany via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:31:35 UTC, Jack wrote:

On Saturday, 19 September 2020 at 13:13:56 UTC, Jack wrote:

Hi,

I am building a webapp using vibe.d which is working well on 
macOS and Linux. However, when I run it on windows I get:

Program exited with code -1073741701

I created a new default project with: dub init test -t vibe.d
and get the same error code when running it.

Any suggestions what could be wrong?


I managed to get it to work with ldc, still not sure why it 
isn't working with dmd.


In case you have an older version of dub, dmd will build an x86 
executable by default with OMF (Windows). Never versions of dub 
defaults to architecture x86_64 with COFF.

LDC builds only COFF for x86 and x86_64.

Kind regards
Andre


Re: Vibe.d

2020-09-19 Thread Andre Pany via Digitalmars-d-learn

On Saturday, 19 September 2020 at 17:57:09 UTC, Andre Pany wrote:

On Saturday, 19 September 2020 at 13:31:35 UTC, Jack wrote:

On Saturday, 19 September 2020 at 13:13:56 UTC, Jack wrote:

Hi,

I am building a webapp using vibe.d which is working well on 
macOS and Linux. However, when I run it on windows I get:

Program exited with code -1073741701

I created a new default project with: dub init test -t vibe.d
and get the same error code when running it.

Any suggestions what could be wrong?


I managed to get it to work with ldc, still not sure why it 
isn't working with dmd.


In case you have an older version of dub, dmd will build an x86 
executable by default with OMF (Windows). Never versions of dub 
defaults to architecture x86_64 with COFF.

LDC builds only COFF for x86 and x86_64.

Kind regards
Andre


Never => newer


Re: Building LDC runtime for a microcontroller

2020-09-19 Thread Imperatorn via Digitalmars-d-learn

On Monday, 7 September 2020 at 22:13:20 UTC, Adam D. Ruppe wrote:

On Monday, 7 September 2020 at 20:55:54 UTC, IGotD- wrote:

[...]


Well, -betterC existed even then, but it was *completely* 
useless. It didn't become useful until 2016 or 2017.


[...]


Cool!


Re: Vibe.d

2020-09-19 Thread Imperatorn via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:13:56 UTC, Jack wrote:

Hi,

I am building a webapp using vibe.d which is working well on 
macOS and Linux. However, when I run it on windows I get:

Program exited with code -1073741701

I created a new default project with: dub init test -t vibe.d
and get the same error code when running it.

Any suggestions what could be wrong?


Any code for us to test?


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Kagamin via Digitalmars-d-learn

if(GetFileType(GetStdHandle(STD_OUTPUT_HANDLE))==FILE_TYPE_PIPE)setvbuf()


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Kagamin via Digitalmars-d-learn
That said, full buffering for pipes may be not all that 
profitable, so it makes sense to always set line buffering for 
pipes and leave full buffering only for file.


Re: Escape this in pure members

2020-09-19 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 19 September 2020 at 16:07:24 UTC, Per Nordlöw wrote:
If an aggregate member is pure but not scope when can it escape 
the `this` pointer?.


Or rather when and, if so, how can the member allow its `this` 
pointer to escape?


It seems to me like the `scope` qualifier is no effect in this 
case.


Escape this in pure members

2020-09-19 Thread Per Nordlöw via Digitalmars-d-learn
If an aggregate member is pure but not scope when can it escape 
the `this` pointer?.


Only via return?

In the struct and class case?


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Anonymouse via Digitalmars-d-learn
On Saturday, 19 September 2020 at 14:08:39 UTC, Adam D. Ruppe 
wrote:
On Saturday, 19 September 2020 at 13:56:53 UTC, Anonymouse 
wrote:
Is there a way to detect programmatically if I'm in an 
environment where I need to manually set line buffering?


Part of the problem is the IDE console and cygwin too I believe 
both *look* like a pipe to the program instead of like an 
interactive terminal, thus why it gets block instead of line 
buffered.


Someone once told me of a trick to detect cygwin specifically 
but I can't access it right now and I'm not sure it would work 
reliably anyway


Just yeah set your expectations low because if it was easy to 
tell programmatically the libc would already do it right.


Also makes sense, thanks. I already expose the option to force 
flushing with a --flush command-line argument, so I guess I'll 
keep that around (but use setvbuf when the TERM/uname thing 
detects a whitelisted environment).


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Anonymouse via Digitalmars-d-learn

On Saturday, 19 September 2020 at 14:14:46 UTC, Paul Backus wrote:
You can check the TERM environment variable [2], or you can use 
the POSIX uname() function [3] to see if you're running under 
Cygwin specifically. If there are any other environments where 
you need to manually set line-buffering, you'll probably have 
to check for those individually as well.


All right, thanks. Yes, currently I'm doing the TERM and uname 
thing on program start and flushing manually after every writeln 
if I detected Cygwin or vscode.


I think I can work with this.



Re: Good repos to learn D

2020-09-19 Thread Imperatorn via Digitalmars-d-learn
On Saturday, 19 September 2020 at 13:13:58 UTC, Jacob Carlborg 
wrote:
On Saturday, 19 September 2020 at 08:26:36 UTC, Imperatorn 
wrote:

[...]


Here are some examples of large projects:

[...]


Thanks, I'll check them out!

/Forsberg


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Paul Backus via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:56:53 UTC, Anonymouse wrote:
On Saturday, 19 September 2020 at 13:32:07 UTC, Paul Backus 
wrote:


http://dpldocs.info/experimental-docs/std.stdio.File.setvbuf.1.html


Thanks.

I don't have a clone of druntime/Phobos available to me right 
now, so some follow-up questions.


It looks like full buffering _IOFBF is the default setting, but 
"normal" non-Cygwin stdio certainly seems to do line buffering. 
Is it getting set to line buffering _IOLBF during 
initialisation of stdout? (Why then is Cygwin exempt?)


This isn't a druntime/Phobos thing, it's a libc thing. Phobos 
just provides a wrapper around it.


My guess is that libc uses something like `isatty(STDOUT_FILENO)` 
to determine if it should use line buffering, and that there's a 
bug in Cygwin that causes isatty() to always return false. If you 
want to know for sure, you can try looking through the Cygwin 
source code. [1]


Is there a way to detect programmatically if I'm in an 
environment where I need to manually set line buffering?


You can check the TERM environment variable [2], or you can use 
the POSIX uname() function [3] to see if you're running under 
Cygwin specifically. If there are any other environments where 
you need to manually set line-buffering, you'll probably have to 
check for those individually as well.


[1] https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git
[2] https://cygwin.com/cygwin-ug-net/setup-env.html
[3] 
https://stackoverflow.com/questions/3466166/how-to-check-if-running-in-cygwin-mac-or-linux


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:56:53 UTC, Anonymouse wrote:
Is there a way to detect programmatically if I'm in an 
environment where I need to manually set line buffering?


Part of the problem is the IDE console and cygwin too I believe 
both *look* like a pipe to the program instead of like an 
interactive terminal, thus why it gets block instead of line 
buffered.


Someone once told me of a trick to detect cygwin specifically but 
I can't access it right now and I'm not sure it would work 
reliably anyway


Just yeah set your expectations low because if it was easy to 
tell programmatically the libc would already do it right.


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Anonymouse via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:32:07 UTC, Paul Backus wrote:
On Saturday, 19 September 2020 at 13:23:29 UTC, Anonymouse 
wrote:

On Tuesday, 18 August 2020 at 06:25:31 UTC, Kagamin wrote:

On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
Just as a drive-by comment, the main stdio thing I came 
across that I couldn't do from within @safe was 
stdout.flush(), which I need to call manually for Cygwin 
terminals and some terminals embedded in editors (vscode). 
If someone knows why, please tell me.


Cygwin terminals are not recognized as terminals, you should 
set line buffered mode, then it will flush every line.


How do I do this?


http://dpldocs.info/experimental-docs/std.stdio.File.setvbuf.1.html


Thanks.

I don't have a clone of druntime/Phobos available to me right 
now, so some follow-up questions.


It looks like full buffering _IOFBF is the default setting, but 
"normal" non-Cygwin stdio certainly seems to do line buffering. 
Is it getting set to line buffering _IOLBF during initialisation 
of stdout? (Why then is Cygwin exempt?)


Is there a way to detect programmatically if I'm in an 
environment where I need to manually set line buffering?




Re: Vibe.d

2020-09-19 Thread Jack via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:13:56 UTC, Jack wrote:

Hi,

I am building a webapp using vibe.d which is working well on 
macOS and Linux. However, when I run it on windows I get:

Program exited with code -1073741701

I created a new default project with: dub init test -t vibe.d
and get the same error code when running it.

Any suggestions what could be wrong?


I managed to get it to work with ldc, still not sure why it isn't 
working with dmd.


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Paul Backus via Digitalmars-d-learn

On Saturday, 19 September 2020 at 13:23:29 UTC, Anonymouse wrote:

On Tuesday, 18 August 2020 at 06:25:31 UTC, Kagamin wrote:

On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
Just as a drive-by comment, the main stdio thing I came 
across that I couldn't do from within @safe was 
stdout.flush(), which I need to call manually for Cygwin 
terminals and some terminals embedded in editors (vscode). If 
someone knows why, please tell me.


Cygwin terminals are not recognized as terminals, you should 
set line buffered mode, then it will flush every line.


How do I do this?


http://dpldocs.info/experimental-docs/std.stdio.File.setvbuf.1.html


Re: Cannot call @system funciton (stdout)

2020-09-19 Thread Anonymouse via Digitalmars-d-learn

On Tuesday, 18 August 2020 at 06:25:31 UTC, Kagamin wrote:

On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
Just as a drive-by comment, the main stdio thing I came across 
that I couldn't do from within @safe was stdout.flush(), which 
I need to call manually for Cygwin terminals and some 
terminals embedded in editors (vscode). If someone knows why, 
please tell me.


Cygwin terminals are not recognized as terminals, you should 
set line buffered mode, then it will flush every line.


How do I do this?


Vibe.d

2020-09-19 Thread Jack via Digitalmars-d-learn

Hi,

I am building a webapp using vibe.d which is working well on 
macOS and Linux. However, when I run it on windows I get:

Program exited with code -1073741701

I created a new default project with: dub init test -t vibe.d
and get the same error code when running it.

Any suggestions what could be wrong?




Re: Good repos to learn D

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn

On Saturday, 19 September 2020 at 08:26:36 UTC, Imperatorn wrote:
What are some good examples of pretty large/medium size, good 
structured repos in D? I'm looking for examples to learn from


Thanks!


Here are some examples of large projects:

* DWT [1]. This is one of the largest D projects I'm aware of. 
It's a port from Java so it's structured like a Java project. I 
think it works pretty well for D projects as well. But it's not 
common to have the reverse domain name package structure like in 
Java. It's more common to have the top level package be named 
after the project.


* Mecca [2]. This one is not as large as DWT, but I think it 
nicely shows how to separate the platform specific code from the 
platform independent code. Instead of having `version` statements 
sprinkled all over the code most platform specific code is 
located in the `platform` packages. Then it provides a common 
interface that is used by the rest of the project.


* Ocean [3]. This one is quite large as well.

[1] https://github.com/d-widget-toolkit/dwt
[2] https://github.com/weka-io/mecca
[3] https://github.com/sociomantic-tsunami/ocean

--
/Jacob Carlborg


Re: DDoc generation

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn
On Saturday, 19 September 2020 at 07:43:24 UTC, Russel Winder 
wrote:


Doesn't that then make the whole DDoc system fairly useless, 
despite it's use in Phobos?


If you use Dub, you can run `dub build -b ddox` and it will use 
Ddox to build the documentation. This will include an index page 
listing all modules. This will actually start a local web server 
to show the documentation. It's possible to generate 
documentation offline as well [1].


Or it should be pretty straightforward to write a simple script 
that iterates all D files and generates documentation. Then 
iterate all HTML files and output a simple index.html file.


[1] 
https://github.com/rejectedsoftware/ddox#generating-offline-documentation


--
/Jacob Carlborg



Re: DDoc generation

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn
On Saturday, 19 September 2020 at 07:43:24 UTC, Russel Winder 
wrote:


Doesn't that then make the whole DDoc system fairly useless, 
despite it's use in Phobos?


Yes.  The problem is that most things in D are compared with C or 
C++. People are praising that the built-in support for unit tests 
and Ddoc are the best things that have happened since sliced 
bread. But if you compare with C or C++ the bar isn't very high.


--
/Jacob Carlborg


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread wjoe via Digitalmars-d-learn

On Friday, 18 September 2020 at 22:21:52 UTC, Adam D. Ruppe wrote:

On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:

[...]


I actually added *exactly* this to cgi.d in... 2010 if I 
remember right. I even kinda documented it: 
http://dpldocs.info/experimental-docs/arsd.cgi.Cgi.UploadedFile.contentInMemory.html


The threshold where it goes to a file is right now 10 MB and 
not configurable, but I've been meaning to go back and clean up 
this api a little. The max file size it accepts is configurable 
 but the threshold where it goes from memory to file is not.




This looks promising. How could I forget about arsd. You have 
something for anything :)


Though I should note that if vibe is putting it in a temporary 
file it probably realistically stays in memory anyway this 
whole thing might be about nothing since the OS is pretty good 
about optimizing temp files.


But if I wanted that sort of "convenience" I would still be using 
PHP ;)


Just I have bigger things to take care of right now (or should 
I say smaller things?!)


:)


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread wjoe via Digitalmars-d-learn

On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:

Are there other frameworks besides vibe that can do what I 
want?


Just FYI, there is also:

https://code.dlang.org/packages/hunt-framework


I never used myself, you need to investigate.


Thanks for the link, I will have a look.


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread ikod via Digitalmars-d-learn

On Saturday, 19 September 2020 at 11:11:21 UTC, ikod wrote:

On Friday, 18 September 2020 at 13:13:16 UTC, wjoe wrote:
On Friday, 18 September 2020 at 12:58:29 UTC, Steven 
Schveighoffer wrote:

On 9/18/20 8:39 AM, Steven Schveighoffer wrote:
But again, solved with an enhancement that allows you to 
process the data in your code. I'll file the enhancement 
request for you, as I think it's a nice addition.


https://github.com/vibe-d/vibe.d/issues/2478

-Steve


Awesome! Thanks a ton :)


My preferable way to handle such thing is: convert incoming 
data into input range of immutable(ubyte)[] and let user to 
consume this range (and handle it as it wish - transform, store 
in memory as is, or dump to disk)


sorry, this looks exactly like it described in proposal (and this 
is how requests works).




Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread ikod via Digitalmars-d-learn

On Friday, 18 September 2020 at 13:13:16 UTC, wjoe wrote:
On Friday, 18 September 2020 at 12:58:29 UTC, Steven 
Schveighoffer wrote:

On 9/18/20 8:39 AM, Steven Schveighoffer wrote:
But again, solved with an enhancement that allows you to 
process the data in your code. I'll file the enhancement 
request for you, as I think it's a nice addition.


https://github.com/vibe-d/vibe.d/issues/2478

-Steve


Awesome! Thanks a ton :)


My preferable way to handle such thing is: convert incoming data 
into input range of immutable(ubyte)[] and let user to consume 
this range (and handle it as it wish - transform, store in memory 
as is, or dump to disk)


Re: vibe.d: How to get the conent of a file upload ?

2020-09-19 Thread wjoe via Digitalmars-d-learn

On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:

[...]


That's what I was trying to answer. When Steve said meh, he 
probably didn't get what I said. Probably its because of my 
typos.


This sort of convenience and productivity benefit is part of 
why I use Node.Js in the job when I need to get things 
doneand not D yet. There are several pieces and bits you 
can't write yourself when working on projects.


In this case you want to get the file(s) in memory...in the 
form of bytes (or buffer) and probably set a file size limit. 
Its all doable through a library but such a library doesn't 
exist in D yet. At least not that I know of.




Yes it would be convenient and thanks for the links but since I'm 
not familiar with Node.js at all parsing the input myself will be 
better than getting into Node.



Vibe.d still lacks many things I personally need... there's 
simply not enough ecosystem third-party libraries.


My first impression of vibe.d is that the author(s) made a 
presumptions about the one way things should be done(tm) and if 
that's not your use case too bad for you.
That's where most of my displeasure of using vibe.d comes from 
and that those aren't described in the documentation - not so 
much because of the things that aren't implemented (yet).


Handling file uploads is one example, another is command line 
arguments.
The presumption here is there is vibe and there can only be vibe. 
It takes them from Runtime.args. Duh?
This didn't make sense to me until I saw example where the 
initialization of vibe was done in a module constructor.
Looks cool on a cursory look but is incredibly impractical if you 
don't want to do it that way. And that's the gist - vibe.d is 
incredibly impractical if your use case doesn't exactly match the 
author(s) assumptions of the one way to do things(tm).
And there are issues with that, too. E.g. in the example the 
server will be started before command line args are completely 
processed. That means if there are wrong or missing or extra args 
the application aborts and leaks OS resources.
The way I would have implemented it is to take args from 
Runtime.args by default but allow passing an args[] to a vibe 
args-handler. I could then parse whatever args I'm interested in 
in my favorite way and pass the rest to vibe.


But you can handle those with vibe getOption or some such - why 
don't you want to do comandline args processing with vibe you ask 
?

Because 1. there's std.getopt which is awesome, and
2. If I don't depend on vibe to parse them and I have a build 
configuration with version="NO_SERVER" I don't even need to link 
against vibe and its dependencies.


By using vibe I feel like I need to bend myself like a snake and 
jump through the hoops of vibe's one way to do it. You save a lot 
of time here and there and then you lose half a day because of 
some stupid road block like the above.


Re: DDoc generation

2020-09-19 Thread Mike Parker via Digitalmars-d-learn

On Friday, 18 September 2020 at 13:35:05 UTC, Russel Winder wrote:
On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via 
Digitalmars-d- learn wrote:


[…]


it ddoc files, and compile those along with your application.

https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation



Any small project examples anywhere?


https://github.com/dlang/dconf.org/tree/master/2019


Good repos to learn D

2020-09-19 Thread Imperatorn via Digitalmars-d-learn
What are some good examples of pretty large/medium size, good 
structured repos in D? I'm looking for examples to learn from


Thanks!


Re: DDoc generation

2020-09-19 Thread Russel Winder via Digitalmars-d-learn
On Fri, 2020-09-18 at 20:22 -0400, James Blachly via Digitalmars-d-learn
wrote:
> On 9/18/20 9:35 AM, Russel Winder wrote:
> > On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via Digitalmars-d-
> > learn wrote:
> > 
> > […]
> > > it ddoc files, and compile those along with your
> > > application.
> > > 
> > > https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation
> > > 
> > 
> > Any small project examples anywhere?
> > 
> 
> I am also learning about ddoc generation (something that IMO could stand 
> to be much better , ahem, documented). A nice example I've found is the 
> libmir site:
> 
> https://www.libmir.org/
> http://mir-algorithm.libmir.org/ (mir-core., mir-random., etc.)
> 
> and its documentation generation infrastructure:
> 
> https://github.com/libmir/circle-dlang

Yikes. Maybe it is just a first sight thing, but if that is what is needed to
handle Mir, maybe I should try and make Doxygen work for my D projects –
though doxygen only works "to some extent D".

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part


Re: DDoc generation

2020-09-19 Thread Russel Winder via Digitalmars-d-learn
On Sat, 2020-09-19 at 08:12 +0200, Jacob Carlborg via Digitalmars-d-learn
wrote:
> On 2020-09-18 13:41, Russel Winder wrote:
> > Hi,
> > 
> > I am trying to get to grips with DDoc for documenting an application.
> > Getting
> > the individual module HTML files seems to be the easy bit. The question is
> > how
> > to get an index.html (or equivalent) so as to have an application level
> > entry
> > point to the generated documentation.
> 
> There's no built-in support for that. You might want to look at some 
> other doc generating tool if those support that.

Doesn't that then make the whole DDoc system fairly useless, despite it's use
in Phobos?

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part


Re: Building LDC runtime for a microcontroller

2020-09-19 Thread Johan via Digitalmars-d-learn

On Friday, 18 September 2020 at 23:00:33 UTC, Adam D. Ruppe wrote:


The error says something about constness being different, well, 
why the eff would an init symbol ever be mutable?


See 
https://forum.dlang.org/post/edngcvtlkjpykxvxy...@forum.dlang.org 
for why TypeInfo is mutable. (In this case, the __initZ symbol is 
more than just an init symbol).


-Johan





Re: Question about linker errors when using slices

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn

On 2020-09-19 04:45, tspike wrote:
I’ve been using D for personal projects for almost a year now and I 
really love it. I recently ran across a linker error that I’m a little 
confused by. Consider the following files:


platform.d:

     module platform;

     import app;

     struct PlatformData
     {
     AppData a;
     }

     void main()
     {

     }

app.d:

     module app;

     struct AppData
     {
     //int* items;
     int[] items;
     }

If you only compile platform.d, the linker will complain about 
“undefined references.” This is true when using dmd and gdc, though 
platform.d compiles just fine when using ldc. But the file only fails to 
compile when the “items” member of AppData is a slice; if “items” is an 
int* platform.d will compile.


The linker spits the following:

     platform.o:(.data._D22TypeInfo_S3app7AppData6__initZ+0x30): 
undefined reference to `_D3app7AppData9__xtoHashFNbNeKxSQBeQBdZm'
     platform.o:(.data._D22TypeInfo_S3app7AppData6__initZ+0x38): 
undefined reference to `_D3app7AppData11__xopEqualsFKxSQBdQBcKxQjZb'


I was just wondering if anyone knows if this behavior is expected or if 
this is a compiler bug. Thank you in advance for your time!


You should compile both files. I'm guessing LDC might be doing some form 
of optimization to figure out that it doesn't need those symbols.



PS: I hope this is the right sub-forum for asking this sort of question!


Yes.

--
/Jacob Carlborg


Re: Proper way to exit with specific exit code?

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn

On 2020-09-17 16:58, drathier wrote:

What's the proper way to exit with a specific exit code?

I found a bunch of old threads discussing this, making sure destructors 
run and the runtime terminates properly, all of which seemingly 
concluding that it's sad that there isn't a way to do this easily, but 
hopefully things have changed in the last 5-10 years and I'm just 
missing the obvious solution.


The proper way is:

int main()
{
return 42;
}

I highly recommend against trying to terminate the application using 
`exit` or any other way. Just let the control flow return back to the 
`main` function.


--
/Jacob Carlborg


Re: DDoc generation

2020-09-19 Thread Jacob Carlborg via Digitalmars-d-learn

On 2020-09-18 13:41, Russel Winder wrote:

Hi,

I am trying to get to grips with DDoc for documenting an application. Getting
the individual module HTML files seems to be the easy bit. The question is how
to get an index.html (or equivalent) so as to have an application level entry
point to the generated documentation.


There's no built-in support for that. You might want to look at some 
other doc generating tool if those support that.


--
/Jacob Carlborg