Re: iopipe code to count lines in gzipped file works with v 0.1.7 but fails with 0.2.1
On 8/7/20 9:31 PM, Steven Schveighoffer wrote: On 8/7/20 8:57 PM, Steven Schveighoffer wrote: I think this is an issue with dub when using an inline recipe file, but I don't know? ugh. This is an issue with iopipe specifying io version 0.2.x. I will fix this. OK, iopipe 0.2.2 is released, with no specific io dependency. It should work with io 0.3.1 as a separate listed dependency. -Steve
Re: How does D's templated functions implementation differ from generics in C#/Java?
On Friday, 7 August 2020 at 21:39:44 UTC, H. S. Teoh wrote: [snip] "Furthermore, it can dispatch to a type-erased implementation ala Java -- at your choice;" This is interesting. Would you just cast to Object?
Re: iopipe code to count lines in gzipped file works with v 0.1.7 but fails with 0.2.1
On 8/7/20 8:57 PM, Steven Schveighoffer wrote: I tried adding dependency "io" version="~>0.3.0" But it fails with: Got no configuration for dependency io ~>0.3.1 of hello ~master!? If I add dependency "io" version="*" it works. I think this is an issue with dub when using an inline recipe file, but I don't know? ugh. This is an issue with iopipe specifying io version 0.2.x. I will fix this. -Steve
Re: iopipe code to count lines in gzipped file works with v 0.1.7 but fails with 0.2.1
On 8/7/20 9:40 AM, Andrew wrote: Hi, This code to count lines in a gzipped file exits with "Program exited with code -9" when run with the latest version of the library, I guess because I am doing unsafe things. BTW the safety improvements only change whether it compiles as @safe or not. If it's building but running is exiting with a code then it's possible there's a bug somewhere. I did have to change a lot of code to get it to build properly. If you have it building, but it's exiting with an error, then please file an issue with an example file and sample source that causes the issue. -Steve
Re: iopipe code to count lines in gzipped file works with v 0.1.7 but fails with 0.2.1
On 8/7/20 9:40 AM, Andrew wrote:
Hi,
This code to count lines in a gzipped file exits with "Program exited
with code -9" when run with the latest version of the library, I guess
because I am doing unsafe things. Could someone tell me how to change it
to make it work? The actual program I'm writing processes a file line by
line, so ideally I'd like to keep the structure of open a file, then
foreach over it.
Thanks very much
As of iopipe v0.2.0, io is no longer a required dependency, it's
optional. So you must also add a dependency for io.
I tried adding
dependency "io" version="~>0.3.0"
But it fails with:
Got no configuration for dependency io ~>0.3.1 of hello ~master!?
If I add
dependency "io" version="*"
it works.
I think this is an issue with dub when using an inline recipe file, but
I don't know?
Note that in this simple example, the line count is stored in the line
pipe, you can retreive the number of lines by accessing the `segments`
member of the pipe (undocumented, I have to fix that). So my code looks
like:
---
/+ dub.sdl:
name "hello"
dependency "iopipe" version="~>0.2.0"
dependency "io" version="*"
+/
import std.stdio;
//import std.typecons; // refCounted not @safe
import iopipe.textpipe;
import iopipe.zip;
import iopipe.bufpipe;
import iopipe.refc; // refCounted that is @safe
import std.io : File = File; // just a note, I don't know why you are
renaming here...
void main() @safe // yay @safe!
{
auto counter = 0;
auto fileToRead = File("file.gz").refCounted.bufd
.unzip(CompressionFormat.gzip)
.assumeText
.byLine;
fileToRead.process();
writeln(fileToRead.segments);
}
---
FYI, I noticed that in my simple test, this outputs one less than the
actual lines. I'll have to look into *that* too.
That dependency on writeln also irks me ;) I need to get working on that
iopipe replacement for it...
-Steve
Re: dpldocs not update
On Friday, 7 August 2020 at 21:58:10 UTC, Per Nordlöw wrote: https://phobos-next.dpldocs.info/index.html aren't updated. For instance the file dpldocs never auto-updates. You must either link to a specific tagged version like this: https://phobos-next.dpldocs.info/v0.3.9/index.html Or go to the page manually and click the little tiny "clear cache" button at the page bottom center. Maybe someday we can link in dub's update to click that button for you but for the foreseeable future you need to hit it yourself to update the docs.
dpldocs not update
I've pushed a new tag several times now and triggered manual update of my https://code.dlang.org/packages/phobos-next but the docs at https://phobos-next.dpldocs.info/index.html aren't updated. For instance the file https://github.com/nordlow/phobos-next/blob/master/src/nxt/open_hashmap.d cannot be found in the listing at https://phobos-next.dpldocs.info/nxt.html What's wrong?
Re: How does D's templated functions implementation differ from generics in C#/Java?
On Friday, 7 August 2020 at 21:03:47 UTC, aberba wrote: Syntactically they look the same (although D's can do more things) so I'm trying to understand how why in D it's called template but in languages like C#/Java they're generics. In D, a copy of the function is created for each new template argument type. In Java (and I assume C# but I don't know for sure), there's just one copy of the function and the types are erased to call it. So let's take a D template `sort(T)(T list)`. The compiler generates nothing until you pass it arguments; it is just a template in its memory. Pass it int[] and it generates a whole new function sort(int[] list). Pass it float[] and it generates another, totally separate function sort(float[] list). Now, take a Java generic function `sort(List list)`. The compiler will generate a function `sort(List list)`. Pass it a List and the compiler actually will just cast it back to the List interface and pass it into the one function it already generated; this creates no new code. At runtime, you cannot tell it was a List, only the compiler knew that*. Pass it a List and again, the compiler will just cast it back to the interface and give it to the same `sort(List list)` function. The actual generic type is known only to the Java compiler and at runtime it is basically a bunch of hidden casts to make it work. * the java runtime is free to optimize a bit more based on usage with its jit compiler but that doesn't change much in the concept. you can read some more here https://en.wikipedia.org/wiki/Generics_in_Java#Problems_with_type_erasure A cool thing with Java's thing though is since they are just special kinds of interface methods you can access generics through runtime reflection in it, whereas D's templates cease to exist at runtime. Only the generated instances of them are around by then since the template itself only lives in the compiler's memory for it to make copies of to generate instances.
Re: How does D's templated functions implementation differ from generics in C#/Java?
On Fri, Aug 07, 2020 at 09:03:47PM +, aberba via Digitalmars-d-learn wrote: > Syntactically they look the same (although D's can do more things) so > I'm trying to understand how why in D it's called template but in > languages like C#/Java they're generics. > > I guess I have fair understanding of D's code generation but isn't it > same as what what is available in those languages too? How are the > implementation different? They are *very* different. Java generics are based on "type erasure", i.e., at the syntactic level, containers are parametrized with the element types, but at the implementation level, the element types are merely "erased" and replaced with Object (a top type of sorts). There is only one container instantiation, which is shared across all parametrizations. I don't know exactly why this approach was chosen, but my guess is, to avoid the complexities associated with templates (esp. as seen in C++, which was the prevailing language with type parametrization when Java generics was being designed), and to avoid template bloat. But because of how this implementation works, Java generics are very limited in a lot of ways that make them feel straitjacketed once you've gotten used to a more powerful template system like in C++ or especially D. Since the container does not retain any information about the type parameter, you cannot perform any type-specific operations on elements (unless you do runtime introspection -- and I'm not even sure Java lets you do this), and you cannot make compile-time decisions based on type properties -- because the single container implementation must be able to handle all type arguments. D templates do not type-erase, and the generated code retains full knowledge about the type parameters. Therefore, you can do very powerful things with them, like Design by Introspection, performing type-specific operations, generate different code depending on type properties, etc.. Since each template instantiation is distinct, it has the flexibility of doing completely different things depending on the type arguments, independently of any other instantiation of the same template. Furthermore, it can dispatch to a type-erased implementation ala Java -- at your choice; and it can even conditionally do so by inspecting the properties of the type arguments. IOW, it is a strict superset of Java generics. Unfortunately, the power of D templates does come at a cost: if used carelessly, it can result in a lot of template bloat. Reducing this bloat often requires delicate code surgery or restriction on some of the flexibility. (Though IMO, this is not a bad thing -- the user is given the *choice* to use a type-erased implementation if he so chooses, or control the template bloat in other ways; in Java, you have no choice but to live with the limitations of a type-erased generics system. But then again, Java has always been a bondage-and-discipline kind of language, so this isn't anything unexpected. People just learn to live with it.) T -- Time flies like an arrow. Fruit flies like a banana.
Re: I just discovered an alternative use of the `in`-operator
On Fri, Aug 07, 2020 at 09:02:03PM +, Per Nordlöw via Digitalmars-d-learn wrote: > On Thursday, 6 August 2020 at 22:24:43 UTC, Paul Backus wrote: > > [1] https://dlang.org/spec/expression.html#is_expression > > I bet there a several places in Phobos where this feature isn't but > could be used. Perhaps. But as I recall, it's widely used throughout Phobos, so it probably won't be easy to find a place where it could be used but isn't. T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Re: I just discovered an alternative use of the `in`-operator
On Friday, 7 August 2020 at 21:02:03 UTC, Per Nordlöw wrote: On Thursday, 6 August 2020 at 22:24:43 UTC, Paul Backus wrote: [1] https://dlang.org/spec/expression.html#is_expression I bet there a several places in Phobos where this feature isn't but could be used. I feel same. That there's a clever use of certain D features waiting to be discovered.
Re: I just discovered an alternative use of the `in`-operator
On Thursday, 6 August 2020 at 22:24:43 UTC, Paul Backus wrote: [1] https://dlang.org/spec/expression.html#is_expression I bet there a several places in Phobos where this feature isn't but could be used.
How does D's templated functions implementation differ from generics in C#/Java?
Syntactically they look the same (although D's can do more things) so I'm trying to understand how why in D it's called template but in languages like C#/Java they're generics. I guess I have fair understanding of D's code generation but isn't it same as what what is available in those languages too? How are the implementation different?
Re: I just discovered an alternative use of the `in`-operator
On Thursday, 6 August 2020 at 22:24:43 UTC, Paul Backus wrote: [1] https://dlang.org/spec/expression.html#is_expression Thanks
Re: Why is time_t defined as a 32-bit type on Windows?
Because it's used with C `time` function https://github.com/dlang/druntime/blob/master/src/core/stdc/time.d#L37 which is provided by msvcrt as 32-bit function. 64-bit variant has a different name.
iopipe code to count lines in gzipped file works with v 0.1.7 but fails with 0.2.1
Hi,
This code to count lines in a gzipped file exits with "Program
exited with code -9" when run with the latest version of the
library, I guess because I am doing unsafe things. Could someone
tell me how to change it to make it work? The actual program I'm
writing processes a file line by line, so ideally I'd like to
keep the structure of open a file, then foreach over it.
Thanks very much
Andrew
/+ dub.sdl:
name "hello"
dependency "iopipe" version="~>0.2.0"
+/
import std.stdio;
import std.typecons;
import iopipe.textpipe;
import iopipe.zip;
import iopipe.bufpipe;
import std.io : File = File;
void main()
{
auto counter = 0;
auto fileToRead =
File("file.gz").refCounted.bufd.unzip(CompressionFormat.gzip);
foreach (line; fileToRead.assumeText.byLineRange!false)
{
counter++;
}
writeln(counter);
}
Re: Is there an alternative of `go get`
On 8/7/20 3:28 AM, Cogitri wrote: On Friday, 7 August 2020 at 07:17:25 UTC, Ky-Anh Huynh wrote: Hi everyone, `go get` in Golang world has a simple way to fetch and install binary ``` $ go get github/foo/bar.git $ export PATH=$PATH:$(go env GOPATH)/bin $ bar --help ``` This saves a lot of time and setup. Is that an alternative when using dub? Hello, you can use `dub build $name` to build the package. The resulting binary should be in $HOME/.dub/$name-$version/$name/bin then. You can also run the binary via `dub run $name -- $additional_args`, then you won't have to add that path to your PATH. If you haven't run `dub build $name` previously, `dub run $name` will do that for you. Having a way to configure the path would be really helpful. I'll add a request for dub. -Steve
Re: Why is time_t defined as a 32-bit type on Windows?
On Friday, 7 August 2020 at 05:37:32 UTC, Andrej Mitrovic wrote: On Wednesday, 5 August 2020 at 16:13:19 UTC, Andrej Mitrovic wrote: ``` C:\dev> rdmd -m64 --eval="import core.stdc.time; writeln(time_t.sizeof);" 4 ``` According to MSDN this should not be the case: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=vs-2019 time is a wrapper for _time64 and **time_t is, by default, equivalent to __time64_t**. But in Druntime it's defined as a 32-bit type: https://github.com/dlang/druntime/blob/349d63750d55d078426d4f433cba512625f8a3a3/src/core/sys/windows/stdc/time.d#L42 I filed it as an issue to get more eyes / feedback: https://issues.dlang.org/show_bug.cgi?id=21134 As far as I gather, this was changed with MSVC 2005 [0], so perhaps the relevent change wasn't applied to the druntime windows bindings. Also keep in mind that we revamped a large portion of the Windows bindins in 2015 [1], whose code was based on MinGW IIRC. In versions of Visual C++ and Microsoft C/C++ before Visual Studio 2005, time_t was a long int (32 bits) and hence could not be used for dates past 3:14:07 January 19, 2038, UTC. time_t is now equivalent to __time64_t by default, but defining _USE_32BIT_TIME_T changes time_t to __time32_t and forces many time functions to call versions that take the 32-bit time_t. For more information, see Standard Types and comments in the documentation for the individual time functions. (^ Source [0]) [0]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/time-management?view=vs-2019 [1]: https://github.com/dlang/druntime/pull/1402 Edit: I see you're discussing core.stdc.time, which actually wasn't part of the changes in [1]. In any case, druntime should offer both time_t, __time32_t, and __time64_t, and have time_t time() default to 64-bit. I do wonder what exactly is exported from UCRT as time(), as from the docs it looks it should be just a macro, but if anyone had used time() one Windows (from D) and didn't get linker errors or memory corruption, then I suppose they're still defaulting it to 32-bit to avoid ABI breakages.
Re: Is there an alternative of `go get`
On Friday, 7 August 2020 at 07:17:25 UTC, Ky-Anh Huynh wrote: Hi everyone, `go get` in Golang world has a simple way to fetch and install binary ``` $ go get github/foo/bar.git $ export PATH=$PATH:$(go env GOPATH)/bin $ bar --help ``` This saves a lot of time and setup. Is that an alternative when using dub? Thanks a lot. Hello, you can use `dub build $name` to build the package. The resulting binary should be in $HOME/.dub/$name-$version/$name/bin then. You can also run the binary via `dub run $name -- $additional_args`, then you won't have to add that path to your PATH. If you haven't run `dub build $name` previously, `dub run $name` will do that for you.
Is there an alternative of `go get`
Hi everyone, `go get` in Golang world has a simple way to fetch and install binary ``` $ go get github/foo/bar.git $ export PATH=$PATH:$(go env GOPATH)/bin $ bar --help ``` This saves a lot of time and setup. Is that an alternative when using dub? Thanks a lot.
