Recommendations for best JSON lib?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

I only need to read arbitrary JSON data, no need for 
writing/(de)serialization.

Re: Cross compile windows programs on linux

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/24/2018 12:30 PM, John Burton wrote:

On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote:

On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote:
Is in the subject. Are there any cross compilers that will run on a 
linux system but compile D code using Win32 into a windows .exe file, 
preferably 64 bit? I can find hints of cross compilers but not really 
seen anything packaged up?


See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org.


Oh thank you.
I did a search but somehow missed that


You could probably also just run the windows version of the compiler 
under wine. I think I remember hearing of people doing that.

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/21/2018 03:27 PM, Steven Schveighoffer wrote:


If you examine how the code for variant works, it's quite clever. It 
establishes a "handler" that is generated with full compile-time type 
info available when the value is *assigned*, but then cast to a function 
taking a void pointer and an operation. This way, the user of the 
variant doesn't have to know what is inside, just the handler does. The 
code that sets the payload is the one that establishes how to use it.


The same type of pattern could be used to, for instance, provide all the 
functions that a range uses.


But it's not something that can be tacked on to Variant. You'd have to 
write your own type, because you'd have to handle the different 
functions that you know are common between the types in question (e.g. 
the operations supported on a variant are here: 
https://github.com/dlang/phobos/blob/master/std/variant.d#L163)


Oooh, that's really cool! I might try my hand at something like that.

I bet it actually could be generalized to a certain extent. Variant 
would just have to be templated on the expected interface. Then it could 
compile-time loop over the list of functions expected, and introspect 
each of them enough to build the handler and the forwarders. Doesn't 
exactly sound fun to implement, but I'd bet it could be done.

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/21/2018 03:03 AM, Nicholas Wilson wrote:
On Monday, 20 August 2018 at 00:27:04 UTC, Nick Sabalausky (Abscissa) 
wrote:
Suppose I've wrapped a Variant in a struct/class which ensures the 
Variant *only* ever contains types which satisfy a particular 
constraint (for example: isInputRange, or hasLength, etc...).


Is there a way to call a function (ex: popFront) on the Variant, 
*without* knowing ahead of time all the possible static types it might 
might contain?


I assume you mean at compile time AoT of development of your library?

Yes, don't use Variant; use https://github.com/s-ludwig/taggedalgebraic



TaggedAlgebraic requires a finite list of every type it can contain. 
That's the deal-breaker for what I had in mind. I need something less 
like Algebraic and more like Variant, which *doesn't* require a finite, 
canonical list of every type it can contain.


The more I think about it though, the more I'm not so sure that the 
extensibility is important enough to warrant all of this, or...more 
importantly...that all of this is even necessary anyway for users to 
accomplish the use-cases I had in mind. I think I may go with an 
entirely different approach.

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/20/2018 10:57 PM, Jonathan M Davis wrote:


Runtime reflection is theoretically possible in D, but it requires
generating the appropriate stuff for every type involved so that the runtime
stuff has something to work with. Java built all of that into the language
and has the JVM to boot, which fundamentally changes some of what can be
done. With D, we're basically in exactly the same boat as C or C++ except
that we have better compile-time type introspection. In principle, a runtime
reflection facility could be built using that, but even if it were part of
Phobos, it would still have to be opt-in. So, I don't know how useful such a
solution would ever be outside of very specific use cases. Regardless, given
that D's object files, linking, etc. are using the C tools, it was never
going to be the case that Java-style runtime reflection would be built in to
D like it is with Java.


Yea. Not to disagree at all with those reasons, but that is unfortunate. 
I've long been interested in how various features of D (not exclusively 
D, though) combine in ways that, in effect, obsolete much of traditional 
OOP inheritence-based polymorphism - offering the same abilities of OOP 
but without many of the notable downsides. Java-style runtime reflection 
would take us that much further in this regard. (Plus, it would make D 
that much more of a universal-toolbox of a language.) Oh well, dreams vs 
reality ;)

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/20/2018 04:34 PM, Jonathan M Davis wrote:


 foreach(T; TypesThatVariantHolds)


Yea, that's what I would've just done, but I wanted to support 
user-created types not already known to my library.



You
can't just call functions on completely unknown types, because the compiler
wouldn't know what code to generate or what to link against.



Right. D's templates have really spoiled me. Because of them, I've grown 
accustomed to invoking functions on unknown types ;)


But you're right, that's not going to work for runtime dispatch without 
enumerating each possible type. Even if I try (like I was thinking) to 
provide a templated function to convert any of the concrete types to an 
internal-only supertype, I'd still need something to runtime dispatch to 
the right template instance. Darn.


A lot of times, I really wish I could introspect across *all* linked 
modules, not just specific ones. Ex: "Hey compiler, give me a 
compile-time list of ALL types in this program with UDA @xyz". Then 
things like this could be built out of that. No need to worry about 
unknown types/symbols because they would all be known and a finite list 
could always be constructed.


Although, what would REALLY be nice is if, for every type, the compiler 
built a list of every member and how to access it (which...really it has 
to do anyway), but then uses that info to build a master runtime 
dispatch system. Types such as Variant already have runtime knowledge of 
what type is currently being held, so that info could be passed to the 
compiler-generated "master runtime dispatch" system along with what 
member to invoke/access.


Come to think of it...aren't I just describing standard run-of-the-mill 
runtime reflection? I mean, hasn't Java already been able to do that for 
ages? But then, in Java everything is already part of the class 
hierarchy anyway so maybe that's why it's possible there?

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/19/2018 11:31 PM, Paul Backus wrote:


You are basically reinventing OOP here.



Yes, I am. Deliberately, in fact. Class inheritance is my backup plan, 
though.


My use-case is actually very, very similar to std.digest:

There are various benefits to using a template-and-constraint based 
interface. But one notable downside is the inability to handle the 
situation where the actual type needed is only known at runtime. In 
std.digest, this dilemma is dealt with by duplicating the entire 
interface in BOTH template/constraint AND class-inheritance varieties.


Additionally, an important thing to note in the case of std.digest is 
that `isDigest!T` returns FALSE for types using the OOP version of the 
interface. I think there is (arguably) a certain merit in that:


The OOP interface obviously uses classes, whereas (in order to obtain 
the full potential benefits of a template-and-constraint approach) the 
template interface uses (and even requires) structs. Because of this, 
instances should be constructed differently ("T instance;" vs "T 
instance = new T();"). Thus, any generic code that wants to handle ANY 
digest type must be very careful to mind this distinction whenever 
creating new instances. Presumably, this may be why std.digest chose to 
NOT let OO digests satisfy the template-oriented isDigest.


And then std.digest also needs WrapperDigest, needed to convert a 
template-style digest to OO-style.


So...while std.digest succeeds at offering the best-of-both-worlds 
between template and OO approaches, it also creates a whole new mess via 
completely duplicated interfaces that aren't 100% compatible.


I want to see if I can do better.

So back to the root of the problem:

We have a bunch of types, including user-defined types we don't have 
advance knowledge of. And we need a type which can hold any of them at 
runtime.


AFAIK, there are two classic ways to do that: One is OOP, the other is 
an unbounded discriminated union (a variant). Unlike class-based 
inheritance, a variant CAN be implemented as a struct. So, at least in 
theory, a variant-based type could potentially be made which implements 
the *true* template-based interface, eliminating the need for duplicate 
APIs and the mess that entails.


There are a bunch of discriminated union types available for D, but the 
only one I'm aware of that *doesn't* require a finite-sized list of 
types known ahead-of-time is Phobos's Variant. The only problem is 
calling a function on a type not already known ahead-of-time. Maybe 
that's unsolvable? If so, then I'll fallback to the std.digest approach. 
But I'd prefer to avoid that, if possible.

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/19/2018 10:23 PM, Jonathan M Davis wrote:

On Sunday, August 19, 2018 6:33:06 PM MDT Nick Sabalausky (Abscissa) via
Digitalmars-d-learn wrote:


Maybe something involving using Variant.coerce to convert the payload to
a single common type? Not sure how I would do that though.


You could always create a wrapper type. Whatever code you're dealing with is
going to need to statically know what type it's using even that's a base
type in a class hierarchy. So, you need to present a type which actually has
the appropriate API even if internally, it can dynamically handle several
types which have that API, and it's not known ahead of time which type that
is.



I guess the parts I'm unclear on are:

1. What mechanism does Variant.coerce!SomeType use to attempt conversion 
to SomeType?


2. How (if possible) can I provide a way to convert something to type 
SomeType which Variant.coerce!SomeType will then recognize and use?

Re: Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 08/19/2018 08:27 PM, Nick Sabalausky (Abscissa) wrote:
Suppose I've wrapped a Variant in a struct/class which ensures the 
Variant *only* ever contains types which satisfy a particular constraint 
(for example: isInputRange, or hasLength, etc...).


Is there a way to call a function (ex: popFront) on the Variant, 
*without* knowing ahead of time all the possible static types it might 
might contain?


Maybe something involving using Variant.coerce to convert the payload to 
a single common type? Not sure how I would do that though.

Generically call a function on Variant's payload?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

Suppose I've wrapped a Variant in a struct/class which ensures the 
Variant *only* ever contains types which satisfy a particular constraint 
(for example: isInputRange, or hasLength, etc...).


Is there a way to call a function (ex: popFront) on the Variant, 
*without* knowing ahead of time all the possible static types it might 
might contain?

Re: docs/definition: !object

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 03/08/2018 05:31 AM, Steven Schveighoffer wrote:

On 3/8/18 1:00 AM, Nick Sabalausky (Abscissa) wrote:


But are we CERTAIN that's all there is to it? I have a non-reduced 
situation right now where outputting the address of a class reveals a 
non-null address, and yet assert(!!theObjectInQuestion) is failing. 
(this is occurring during stack unwinding, if that makes a difference)


Turns out it wasn't a class at all: As Jacob pointed out in my other 
thread, it *used* to be a class/interface in a previous lib version 
(vibe's TCPConnection) but got changed to a struct without my noticing. 
Hence the seemingly weird behaviours.




One thing to keep in mind, assert(someObject) does more than just check 
if it's not null, it also runs the object's invariant to see if it's valid.




Ahh, right! *That's* the part I knew I'd heard about and was trying to 
remember.

Re: Can't "is null" an interface?!?! Incompatible types???

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 03/08/2018 03:04 AM, Nick Sabalausky (Abscissa) wrote:


Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to 
work on run.dlang.io). But it does seem to work for me if I use 
'v0.8.3-alpha.1'.


I wonder what could have changed to result in this?


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

Re: Can't "is null" an interface?!?! Incompatible types???

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 03/08/2018 01:13 AM, Nicholas Wilson wrote:


That does seem odd.
---
/+dub.sdl:
dependency "vibe-d" version="~>0.8.3-alpha.1"
+/
import vibe.core.net;
import std.stdio;
TCPConnection mySocket;

void main() {
     auto b = mySocket is null;
     writeln(b);
}
---
works fine on run.dlang.io


Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to 
work on run.dlang.io). But it does seem to work for me if I use 
'v0.8.3-alpha.1'.


I wonder what could have changed to result in this?

Re: docs/definition: !object

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 03/08/2018 12:05 AM, ketmar wrote:

Nick Sabalausky (Abscissa) wrote:

I'm having trouble finding the documentation for what exactly the 
unary "not" operator does when applied to a class/interface object. 
Does this documentation exist somewhere?


I know at least part of it involves "is null", but I seem to remember 
hearing there was more to it than just that.


https://dlang.org/spec/operatoroverloading.html#boolean_operators

"Class references are converted to bool by checking to see if the class 
reference is null or not."


Ah, thanks.

But are we CERTAIN that's all there is to it? I have a non-reduced 
situation right now where outputting the address of a class reveals a 
non-null address, and yet assert(!!theObjectInQuestion) is failing. 
(this is occurring during stack unwinding, if that makes a difference)


(Or does &someObject return the address of the *reference* to the object 
rather than the address of the object?...You can see just how often I do 
OO in D ;) )

docs/definition: !object

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

I'm having trouble finding the documentation for what exactly the unary 
"not" operator does when applied to a class/interface object. Does this 
documentation exist somewhere?


I know at least part of it involves "is null", but I seem to remember 
hearing there was more to it than just that.

Can't "is null" an interface?!?! Incompatible types???

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

-
import vibe.core.net;
TCPConnection mySocket;

void main() {
auto b = mySocket is null;
}
-

That's giving me:

-
Error: incompatible types for (mySocket) is (null): TCPConnection and 
typeof(null)

-

WTF?!?!

The type in question (vibe.core.net.TCPConnection) is an interface:
http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344

The following works just fine:
-
interface IFoo {}

void main() {
IFoo i;
auto b = i is null;
}
-

Spawning a process: Can I "have my cake and eat it too"?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

I'd like to include this functionality in Scriptlike, but I don't know 
if it's even possible:


Launch a process (spawnProcess, pipeShell, etc) so the child's 
stdout/stderr go to the parent's stdout/stderr *without* the possibility 
of them getting inadvertently reordered/reinterleaved when viewed on the 
terminal, *and* still allow the parent to read the child's stdout and 
stderr?


How could this be accomplished? Is it even possible?

Tuts/Aritcles: Incrementasl C++-to-D conversion?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

Are there any tutorials or articles out there for "getting started with 
converting a C++ codebase to D one module at a time?" Or at the very 
least: tips, tricks, lessions learned, from those who have come before.

Re: No line numbers in stack trace (again)

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 12/05/2017 08:43 AM, Nordlöw wrote:
If I get the following stack trace ___without line numbers___ (instead 
??:?) what's missing?




Linux stack trace line numbers have disappeard for me, too. Used to 
work. Very frustrating, and a royal PITA when dealing with unittests. 
Help would be appreciated. Could it be a PIC thing?

Re: git workflow for D

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 12/03/2017 03:05 PM, bitwise wrote:
I've finally started learning git, due to our team expanding beyond one 
person - awesome, right? 


PROTIP: Version control systems (no matter whether you use git, 
subversion, or whatever), are VERY helpful on single-person projects, 
too! Highly recommended! (Or even any time you have a directory tree 
where you might want to enable undo/redo/magic-time-machine on!)



Anyways, I've got things more or less figured 
out, which is nice, because being clueless about git is a big blocker 
for me trying to do any real work on dmd/phobos/druntime. As far as 
working on a single master branch works, I can commit, rebase, merge, 
squash, push, reset, etc, like the best of em.


Congrats! Like Arun mentioned, git's CLI can be a royal mess. I've heard 
it be compared to driving a car by crawling under the hood and pulling 
on wires - and I agree.


But it's VERY helpful stuff to know, and the closer you get to 
understanding it inside and out, the better off you are. (And I admit, I 
still have a long ways to go myself.)


What I'm confused about 
is how all this stuff will interact when working on a forked repo and 
trying to maintain pull requests while everyone else's commits flood in.


Yea. It's fundamental stuff, but it can be frustratingly convoluted for 
the uninitiated. TBH, I really wish we had widespread tools that cater 
to what have emerged as the most common best-practice workflows and the 
basic primitives of those workflows. I even went so far as to get 
started on such a tool (I call it "wit"), but it's been kind of on the 
back burner lately, and it's still far too embryonic for any kind of 
release. (I am still using a git repo for it locally though! Again, 
highly recommeded. At the very least, just because there's nothing worse 
than accidentally loosing a bunch of important code, or finding you need 
to undo a bunch of changes that didn't work out.)


One thing to keep in mind: Any time you're talking about moving anything 
from one repo to another, there's exactly two basic primitives there: 
push and pull. Both of them are basically the same simple thing: All 
they're about is copying the latest new commits (or tags) from WW branch 
on XX repo, to YY branch on ZZ repo. All other git commands that move 
anything bewteen repos start out with this basic "push" or "pull" 
primitive. (Engh, technically "fetch" is even more of a primitive than 
those, but I find it more helpful to think in terms of "push/pull" for 
the most typical daily tasks.)


How does one keep their fork up to date? For example, if I fork dmd, and 
wait a month, do I just fetch using dmd's master as a remote, and then 
rebase?


Yes. "pull" from the official ~master to your local repo's ~master, if 
necessary rebasing your changes on top of the new ~master. Although 
generally, you shouldn't have much (or any) changes in your own ~master 
branch, so typically the rebase part really shouldn't be needed at all, 
since you shouldnt have any local changes on ~master which would need to 
be rebased (this ideal is a situation git refers to as "fast-forward").


Unless, of course, you happen to be futzing around making some changes 
and making your commits to your ~master (which you're not *supposed* to 
be doing anyway - standard best practice is to do all your work within a 
branch). In this case you probably will need to rebase. (The other 
alternative to rebasing is always a merge, but in the specific situation 
you're describing, rebase is definitely cleaner and will lead to less 
problems).



Will that actually work,


Yes.

or is that impossible across separate 
forks/branches?


Totally possible. In fact, that's exactly the sort of stuff git is 
designed to handle.


What if I have committed and pushed to my remote fork 
and still want to merge in the latest changes from dlang's master branch?




You pretty much already got this right. First, you do just as you said 
above:


1. Pull from the official repo's ~master to your local repo's ~master 
(rebasing, if necessary, any commits you may have on your local ~master. 
Although, like Bastile said, if you're making local commits to ~master 
then *technically* "you're doing it wrong").


2. And then, after you've pulled (and maybe rebased) the lastest 
official updates to your local machine...maybe then you added some more 
commits of your own...then you can push it all from your local machine's 
clone to your remote fork.


Think of your remote github fork as the "published" copy of your local 
repo. It should exactly mirror your local repo (minus whatever 
branches/commits you're not yet ready to unleash upon the world): You do 
your work locally, and whenever you want to "publish" or "make public" 
your local work, you push it from your local repo to your remote github 
fork. That's all your remote github fork is: A copy of your whatever 
parts of your local repo that you've chosen to publish.



And how does a pull request actuall

Re: Struct inside a class: How to get outer?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 12/03/2017 03:46 AM, bauss wrote:

On Sunday, 3 December 2017 at 07:38:47 UTC, Jonathan M Davis wrote:
As I understand it, there is no outer for nested structs, only nested 
classes. So, you'll either have to use a nested class or explicitly 
pass a reference to the outer class to the nested struct.



It wouldn't make much sense either, if a struct  was able to do it.



Why is that?

Struct inside a class: How to get outer?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

Is this even possible? My attempts:

class Outer {
struct Inner {
void foo() {
// Error: no property 'outer' for type 'Inner'
Outer o = this.outer;

// Error: cannot implicitly convert expression
// this of type Inner to testNested.Outer
Outer o = this;
}
}
}

gdc-6.3.0 on travis borked?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

When using gdc-6.3.0 on travis-ci, travis is reporting that it can't 
download the compiler:


--
$ source "$(CURL_USER_AGENT="$CURL_USER_AGENT" bash install.sh gdc-6.3.0 
--activate)"


curl: (22) The requested URL returned error: 404 Not Found

curl: (22) The requested URL returned error: 404 Not Found

curl: (22) The requested URL returned error: 404 Not Found

curl: (22) The requested URL returned error: 404 Not Found

curl: (22) The requested URL returned error: 404 Not Found

Failed to download 
'http://gdcproject.org/downloads/binaries/x86_64-linux-gnu/gdc-6.3.0.tar.xz'


/home/travis/.travis/job_stages: line 57: : No such file or directory

The command "source "$(CURL_USER_AGENT="$CURL_USER_AGENT" bash 
install.sh gdc-6.3.0 --activate)"" failed and exited with 1 during .

--

Anyone know anything about this? Where (and to whom) should this be 
reported?

Re: Range tee()?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 10/16/2017 03:30 AM, lobo wrote:
On Monday, 16 October 2017 at 07:28:03 UTC, Nick Sabalausky (Abscissa) 
wrote:

Does Phobos have a way to "tee" a range?

For example, suppose you had something like this:

[...]


https://dlang.org/phobos/std_range.html#tee ?


Ahh, thanks, I was only looking in std.algorithm. Didn't expect it to be 
in std.range.

Range tee()?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

Does Phobos have a way to "tee" a range?

For example, suppose you had something like this:

-
// Do something with each file in a dir
dirEntries(selectedDir, SpanMode.shallow)
.filter!someFilterCriteria
.doSomethingWithFile;
-

It would be really nice to be able to "wiretap" that, to trace/debug/etc 
by nothing more than ADDING a single statement at any desired wiretap point:


-
// Do something with each file in a dir
dirEntries(selectedDir, SpanMode.shallow)
//.tee(a => writeln("FOUND: ", a))  // DEBUG: TRACE ALL FILES FOUND!
.filter!someFilterCriteria
//.tee(a => writeln("SELECTED: ", a))  // DEBUG: TRACE RESULT OF 
FILTER!

.doSomethingWithFile;
-

Does something like this already exist Phobos? I tried looking for a 
"tee" in st.algorithm but came up nothing. If not, it seems like a 
pretty glaring omission.

Re: problem with std.variant rounding

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 05/02/2017 04:02 AM, Suliman wrote:


I need co concatenate string with variant type (I am doing SQL query).

What is the best way to put it? It's seems that if I am doing simple
`replace`

string sql = "..."
sql.replace(`37.72308`, to!string(cargpspoint.lon)).replace(`55.47957`,
to!string(cargpspoint.lat))

I am loosing accuracy. Is there any better way?


Building SQL strings manually isn't really good practice these days, for 
both that and other reasons. It's better to use prepared statements, 
which will fix that issue for you and will also ensure your code is not 
susceptible to SQL-injection attacks:



// Raw SQL strings (old, ugly, unsafe way):
auto name = "Fred";
auto num = 1.23;
auto sql = text(
  "INSERT INTO `myTable` (`field1`, `field2`) VALUES ('",
  mysqlEscape(name), "', ", num, ")"
);
exec(conn, sql);


// Prepared statement (good, modern, safe way):
auto name = "Fred";
auto num = 1.23;
Prepared insertSomeFields = prepare(conn,
  "INSERT INTO `myTable` (`field1`, `field2`) VALUES (?, ?)"
);
insertSomeFields.setArgs(name, num);
insertSomeFields.exec();

Re: GC: Understanding potential sources of false pointers

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 04/22/2017 08:56 AM, Kagamin wrote:

.rdata is fine, but afaik you have only strings there, the rest - .data,
.bss, .tls will suffer the same issue.


I don't know anything about the various object file sections. :/

Re: GC: Understanding potential sources of false pointers

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 04/20/2017 09:00 AM, Kagamin wrote:

https://issues.dlang.org/show_bug.cgi?id=15723


Hmm, so apparently embedded data (even if it's from a C lib) can also be 
a source of false pointers. Thanks, good to know.

Re: Can we disallow appending integer to string?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 04/19/2017 01:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:


Yeah, which reduces the number of casts required when doing arithmetic on
characters and thus reduces bugs there,


Ugh, because apparently doing arithmetic on characters is such a common, 
important use-case in this modern unicode world... :/

GC: Understanding potential sources of false pointers

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

According to :

"Registers, the stack, and any other memory locations added through the 
GC.addRange function are always scanned conservatively."


1. Can that be safely assumed to be a canonical list of all possible 
sources of false pointers?


2. What about memory allocated through language constructs such as 
"new", append ("~"/"~="), closures, or any others I may be forgetting? 
Is this memory always/never/sometimes set to NO_SCAN? (I assume not 
"always", as that would be silly.) If "sometimes", what are the conditions?


A couple specific examples:

3. Are there any situations where a (for example) int[] or long[] that 
is stored on the GC heap could lead to false pointers?


4. Same question as #3, but if it's an array of structs, and the struct 
type contains no members that are statically-typed as pointers.

Re: ddoc: Can I escape a colon?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 02/23/2017 10:36 PM, Adam D. Ruppe wrote:

On Friday, 24 February 2017 at 02:50:27 UTC, Nick Sabalausky (Abscissa)
wrote:

What I'd kinda like to do is put together a D doc generator that uses,
uhh, probably markdown.


My dpldocs.info generator continues to progress and I'm almost ready to
call it beta and let other people use it.

It's syntax is a hybrid of ddoc and markdown. Take a look at the sample
page: http://dpldocs.info/experimental-docs/test.html


Oh, nice. The $(MATH stuff is especially cool (although unlikely to be 
useful in my libs - damn! I wanna put that to use!).


Looking forward to seeing that hit beta (and beyond) and trying that out.

Re: Big Oversight with readln?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 02/23/2017 09:43 PM, Jonathan Marler wrote:

I can't figure out how to make use of the full capacity of buffers that
are allocated by readln.  Take the example code from the documentation:

 // Read lines from $(D stdin) and count words

 void main()
 {
 char[] buf;
 size_t words = 0;

 while (!stdin.eof)
 {
 char[] line = buf;
 stdin.readln(line);
 if (line.length > buf.length)
 buf = line;

 words += line.split.length;
 }

 writeln(words);
 }

When buf is not large enough to hold the line, readln will allocate a
new buffer to accomodate and this example shows how you can save that
new buffer to reuse the next time.  The problem is that the capacity of
the new buffer is nowhere to be found. readln only returns the line that
was read which is only a slice of the buffer that was allocated.  The
next time that readln is called, it will not read past the slice even if
the capacity of the buffer it allocated was larger.  This will cause a
new allocation/copy every time you read a line that was larger than all
the previous lines, even if a previous allocation was already large
enough. This seems like a big oversight to me, I must be missing
something right?


I don't think that problem is actually occurring:

Let's step through the code, and suppose you're reading the following 
four lines of text:


12345
123456789
123
1234567

Starting out, buf.length is 0. When reading the first line, the buffer 
isn't big enough for 5, so readln allocates returns new buffer of length 
5. That is more than buf.length (0), so the new buffer becomes the new buf.


Second line, again, buf (length 5) isn't big enough for 9, so readln 
allocates a new buffer length 9. That's more than the old one (5), so 
again your code sets buf to the larger new buffer (length 9).


Third line: buf (length 9) can definitely hold length 3, so readln does 
not allocate. The new slice returned (length 3) is NOT longer than buf 
(still length 9), so buf is NOT set to the slice returned by readln. So 
buf REMAINS length 9.


Fourth line: buf (still length 9) can definitely hold length 7, so 
readln does not allocate.

Re: ddoc: Can I escape a colon?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 02/23/2017 04:34 PM, Ali Çehreli wrote:


(None of the following is tested.)

a) Try using the following macro:

 COLON = :

And then use "Note$(COLON) Blah".



Thanks, that works.


c) Another option:

 NOTE = Note: $0

Then use "$(NOTE Blah)"


Actually, that's more or less what I was already doing anyway (for a 
changelog):


ENHANCE  = $(LI $(B Enhancement:) $0)
CHANGE   = $(LI $(B Change:) $0)
FIXED= $(LI $(B Fixed:) $0)

But the section interpretation there wasn't playing nice with newer 
versions of ddox. Using that "COLON = :" trick fixed it though (and 
does indeed appear to work outside of these macros, too.

Re: ddoc: Can I escape a colon?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 02/23/2017 04:49 PM, H. S. Teoh via Digitalmars-d-learn wrote:


I'm becoming more and more convinced that software that tries to be
smart ends up being even dumber than before.


I've been convinced of that for a long time ;) Not just software either. 
Anything. My car does idiotic "smart" junk that irritates the crap out 
of me and makes me wish my 1997 Prizm hadn't finally rusted itself to 
pieces. K.I.S.S.

Re: ddoc: Can I escape a colon?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 02/23/2017 04:51 PM, Adam D. Ruppe wrote:

On Thursday, 23 February 2017 at 21:39:11 UTC, H. S. Teoh

Apparently COLON is defined to be ':' in the default ddoc macros, so
you needn't define it yourself.


Oh yeah.

Still, barf.


Luckily in my case, the "Word:" part is already generated inside a ddoc 
macro, so it'll be just as well hidden.


What I'd kinda like to do is put together a D doc generator that uses, 
uhh, probably markdown. But still with some sort of basic (but 
better-looking than ddoc) macro system, because link URLs can still 
REALLY clutter up even markdown source and make it unreadable (which is 
why I actually ended up converting the changelog for at least one of my 
projects from markdown to ddox.) Not a high enough priority for me now 
though :(

ddoc: Can I escape a colon?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

Suppose I want ddoc output to include this line:

--
Note: Blah blabbety blah
--

But the colon causes "Note" to be considered a section header. Is there 
a way to escape the ":" so that it's displayed as expected, but doesn't 
trigger a section?