How to split a string to a 2D array
I want to convert a string like " a,b1, 23 " to a
2D array like:
[["a", "b"],
["1", "2"],
["3", "" ]]
auto html = " a,b1, 23 ";
auto rows = html.strip.chomp("").split("");
string[][] data;
rows.each!(a => data ~= a.split(","));
string[][] result = data.map!(a => a.padRight("",
data[0].length).map!(b => b.strip)).array;
but the result is not a string[][]:
Error: cannot implicitly convert expression `array(map(data))` of
type `MapResult!(__lambda2, Result)[]` to `string[][]`
Re: Game and GC
On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote: Hi, I'm new to language and games. Many people say that GC is bad and can slow down your project in some moments. What can happen if I create a game using D without worrying with memory management? (using full GC) From my experience a combination of the following is necessary: - not having the audio thread registered - using pools aggressively for game entities
Re: Template Constraints
On Saturday, February 24, 2018 04:33:52 psychoticRabbit via Digitalmars-d- learn wrote: > On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis > > wrote: > > Why is there anything dodgy going on and why would you need > > contracts? Contracts actually tend to go very badly with > > generic code, because whatever they assert has to be generic, > > and while that works sometimes, more often than not, it doesn't. > > > > - Jonathan M Davis > > what if 3.3 is passed to the template, and it explicately casts > it to an int. > > To me, that would be dodgy It could be exactly how the function is intended to work, since that's how casting to int works for float. And there's nothing dodgy about a cast from float to int losing the part of the value to the right of the decimal place. That's the expected behavior. > - unless there was a contract, that I > had accepted and agreed to, so that this not dodgy. All contracts are are assertions. That's it. There's nothing special about them. An in contract is used to verify that the function is given valid data, but there really isn't any accepting or agreeing to a contract. Rather, it's something that blows up in your face if you give it bad data so that you can catch bugs. Presumably, the documentation gives the requirements for the function if it has them, and then an in contract can be used to verify that the arguments don't violate those requirements, but all it is is a tool for catching bugs. And there isn't necesarily anything buggy about casting 3.3 to an int. That depends entirely on what the code is supposed to be doing. Now, by having the function simply accept int you avoid the entire question, because then it's up to the caller to decide how they go about converting to int, and I'd argue that that's better in general, but there are times when casting within the function may make more sense. - Jonathan M Davis
Re: Template Constraints
On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis wrote: Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't. - Jonathan M Davis what if 3.3 is passed to the template, and it explicately casts it to an int. To me, that would be dodgy - unless there was a contract, that I had accepted and agreed to, so that this not dodgy.
Re: Template Constraints
On Sat, Feb 24, 2018 at 02:54:13AM +, Jonathan via Digitalmars-d-learn
wrote:
> I am having trouble finding many useful explanations of using template
> constraints beyond basic usage.
>
> I would like to have a template constrant to enforce that a type can
> be explicitly cast to another type:
>
> void (T)(T t)
> if (cast(int) T)//force `cast(int) T` to be possible
> {
> // Yay I know `t` can be cast to an `int`!
> }
>
> Is this possible?
Yes:
void (T)(T t)
if (is(typeof(cast(int) T.init)))
{
...
}
Explanation:
- is(X) generally means "is X a valid type?". It's the usual way of
testing whether something is valid, because an invalid expression will
have no type, and is(X) will return false for it.
- To make use of is(X), generally you want to use typeof to extract the
type of some test expression.
- T.init is the usual D way of saying "give me an instance of type T",
because every type has an .init.
- Putting it together, we have our test object T.init, and our test
expression `cast(int) T.init`, extract the type of that using typeof,
and use the is(...) operator to test whether that type exists.
T
--
I think Debian's doing something wrong, `apt-get install pesticide', doesn't
seem to remove the bugs on my system! -- Mike Dresser
Re: Template Constraints
On Saturday, February 24, 2018 04:13:30 psychoticRabbit via Digitalmars-d- learn wrote: > On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis > > wrote: > > Whether an implicit cast or an explicit cast makes more sense > > depends entirely on what the code is doing, but either way, the > > conversion needs to be forced inside the function, or you end > > up with bugs. Far too often, when someone has a template > > constraint that checks an implicit conversion, the function > > doesn't actually force the conversion, and that can do anything > > from resulting in some instantiations not compiling to causing > > subtle bugs due to the argument being used without being > > converted. In general, it's actually best to avoid conversions > > entirely with generic code and force the caller to do the > > conversion if a conversion is appropriate. > > > > But ultimately, what works best depends on what the code is > > trying to do. > > > > - Jonathan M Davis > > yeah it's hard to say much more without knowing what the code > really wants to do..but presumably, you'd want to incorporate > some contract programming in such a solution too, particulary > given there's something potentially dodgy going on within such a > function. Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't. If you're testing for a conversion in a template constraint, simply forcing the conversion by assigning it to a variable of the target type (with an explicit cast if necessary) solves all of the problems related to testing for a conversion and then writing the code as if the argument were of the target type rather than a type that converted to the target type. - Jonathan M Davis
Re: Template Constraints
On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis wrote: Whether an implicit cast or an explicit cast makes more sense depends entirely on what the code is doing, but either way, the conversion needs to be forced inside the function, or you end up with bugs. Far too often, when someone has a template constraint that checks an implicit conversion, the function doesn't actually force the conversion, and that can do anything from resulting in some instantiations not compiling to causing subtle bugs due to the argument being used without being converted. In general, it's actually best to avoid conversions entirely with generic code and force the caller to do the conversion if a conversion is appropriate. But ultimately, what works best depends on what the code is trying to do. - Jonathan M Davis yeah it's hard to say much more without knowing what the code really wants to do..but presumably, you'd want to incorporate some contract programming in such a solution too, particulary given there's something potentially dodgy going on within such a function.
Re: Template Constraints
On Saturday, February 24, 2018 03:48:44 psychoticRabbit via Digitalmars-d- learn wrote: > On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis > > wrote: > > That does not do what the OP requested at all. That tests > > whether T is one of byte, ubyte, short, ushort, int, uint, > > long, and ulong, whereas what the OP wants is to test whether T > > can be cast to int. > > > > - Jonathan M Davis > > yeah. I realised that after I had posted. > > I posted a more suitable response after that though (I hope), > with the intention of leading the OP away from an explicit cast, > towards an implicit cast. Whether an implicit cast or an explicit cast makes more sense depends entirely on what the code is doing, but either way, the conversion needs to be forced inside the function, or you end up with bugs. Far too often, when someone has a template constraint that checks an implicit conversion, the function doesn't actually force the conversion, and that can do anything from resulting in some instantiations not compiling to causing subtle bugs due to the argument being used without being converted. In general, it's actually best to avoid conversions entirely with generic code and force the caller to do the conversion if a conversion is appropriate. But ultimately, what works best depends on what the code is trying to do. - Jonathan M Davis
Re: Template Constraints
On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis wrote: That does not do what the OP requested at all. That tests whether T is one of byte, ubyte, short, ushort, int, uint, long, and ulong, whereas what the OP wants is to test whether T can be cast to int. - Jonathan M Davis yeah. I realised that after I had posted. I posted a more suitable response after that though (I hope), with the intention of leading the OP away from an explicit cast, towards an implicit cast.
Re: Template Constraints
On Saturday, 24 February 2018 at 03:30:45 UTC, psychoticRabbit
wrote:
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be
possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");
}
or this is probably more suitable ;-)
(should you really be using an explicity convert anyway?)
void testTemplate2(T)(T x) if (isImplicitlyConvertible!(T, int))
{
writeln(x, " is implicitly convertible to an int. yeah!");
}
Re: Template Constraints
On Saturday, February 24, 2018 03:30:45 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
> > I am having trouble finding many useful explanations of using
> > template constraints beyond basic usage.
> >
> > I would like to have a template constrant to enforce that a
> >
> > type can be explicitly cast to another type:
> > void (T)(T t)
> >
> > if (cast(int) T)//force `cast(int) T` to be possible
> >
> > {
> >
> > // Yay I know `t` can be cast to an `int`!
> >
> > }
> >
> > Is this possible?
>
> import std.traits : isIntegral;
> void testTemplate(T)(T x) if (isIntegral!T)
> {
> writeln(x, " is an integral. yeah!");
>
> }
That does not do what the OP requested at all. That tests whether T is one
of byte, ubyte, short, ushort, int, uint, long, and ulong, whereas what the
OP wants is to test whether T can be cast to int.
- Jonathan M Davis
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");
}
Re: Template Constraints
On Saturday, February 24, 2018 03:04:53 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
> > I am having trouble finding many useful explanations of using
> > template constraints beyond basic usage.
> >
> > I would like to have a template constrant to enforce that a
> >
> > type can be explicitly cast to another type:
> > void (T)(T t)
> >
> > if (cast(int) T)//force `cast(int) T` to be possible
> >
> > {
> >
> > // Yay I know `t` can be cast to an `int`!
> >
> > }
> >
> > Is this possible?
>
> I would have thought contracts would be ideal here?
>
> https://dlang.org/spec/contracts.html
Contracts are used to assert runtime state, whereas template constraints
control which arguments can be used with the template (including being used
for function overloading).
The OP wants his function template to reject any arguments that can't be
explicitly cast to int, whereas an in contract would be used for something
like verifying at runtime that the argument was within a particular range of
values.
- Jonathan M Davis
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
I would have thought contracts would be ideal here?
https://dlang.org/spec/contracts.html
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
The constraint is just like static if as to what it allows
inside, so you can check almost anything in there.
Like for the cast, you might do
void name(T)(T t) if(__traits(compiles, cast(int) t) {}
just seeing it the cast compiles.
You might also do
if(is(T : int))
which asks if T is implicitly convertible to int. But since you
want explicit cast, the compiles is prolly the way to go.
is: https://dlang.org/spec/expression.html#IsExpression
compiles: https://dlang.org/spec/traits.html#compiles
Re: Template Constraints
On Saturday, February 24, 2018 02:54:13 Jonathan via Digitalmars-d-learn
wrote:
> I am having trouble finding many useful explanations of using
> template constraints beyond basic usage.
>
> I would like to have a template constrant to enforce that a type
> can be explicitly cast to another type:
>
> void (T)(T t)
> if (cast(int) T)//force `cast(int) T` to be possible
> {
> // Yay I know `t` can be cast to an `int`!
> }
>
> Is this possible?
Well, template constraints in general usually either test that the type of
one expression matches another or that a particular piece of code compiles.
So, you'd need to test that the cast compiles. That requires either an is
expression or __traits(compiles, ...) (or an eponymous template that
contains such an expression). In this case, you could probably just do
if(is(typeof(cast(int)t)))
since as long as the result of the expression isn't void, the is expression
will be true.
And note that the expression uses t, not T. You can't cast the type itself.
You have to cast a value of that type.
- Jonathan M Davis
Template Constraints
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a type
can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
Re: Vibe.d no more using static this() {}
On Friday, 23 February 2018 at 23:11:13 UTC, aberba wrote:
I recently noticed vibe.d now using main loop which call the
vibe.d event loop. Why that change?
Like:
#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
import vibe.d;
void main()
{
auto settings = new HTTPServerSettings;
settings.port = 8080;
listenHTTP(settings, (req, res) { res.writeBody("Hello
Vibe.d: " ~ req.path); });
runApplication();
}
Vibe.d no more using static this() {}
I recently noticed vibe.d now using main loop which call the vibe.d event loop. Why that change?
Re: Help using lubeck on Windows
On Friday, 23 February 2018 at 12:13:11 UTC, Arredondo wrote: Help using lubeck on Windows I'd like to experiment with linear algebra in D, and it looks like lubeck is the way to do it right now. However, I'm having a hard time dealing with the CBLAS and LAPACK dependencies. I downloaded the OpenBLAS binaries for Windows (libopenblas.dll), but I am cluless as to what to do with them. I can't find an example of how to link them/what commands to pass to dmd. Any help deeply appreciated. openblas.net contains precompiled openblas library for Windows. It may not be optimised well for exactly your CPU but it is fast enought to start. Put the library files into your prodject and add openblas library to your project dub configuration. A .dll files are dinamic, you need also a .lib /.a to link with. OpenBLAS contains both cblas and lapack api by default. We defenetely need to add an example for Windows Best Ilya
Re: Tuts/Aritcles: Incrementasl C++-to-D conversion?
On Thursday, 22 February 2018 at 04:16:44 UTC, Nick Sabalausky (Abscissa) wrote: 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. AFAIK, visuald has a tool that just translated C++ to D https://github.com/dlang/visuald/tree/master/c2d
Re: Help using lubeck on Windows
On Friday, 23 February 2018 at 12:13:11 UTC, Arredondo wrote: Help using lubeck on Windows I'd like to experiment with linear algebra in D, and it looks like lubeck is the way to do it right now. However, I'm having a hard time dealing with the CBLAS and LAPACK dependencies. I downloaded the OpenBLAS binaries for Windows (libopenblas.dll), but I am cluless as to what to do with them. I can't find an example of how to link them/what commands to pass to dmd. Any help deeply appreciated. It is a rather frustrating experience on Windows. I've banged my head against my desk a few times trying to get it working. My suggestion is to get the Windows Subsystem for Linux set up. With Ubuntu, you can follow all of the Linux instructions and it is pretty easy. For trying to get it to work on Windows, first look at lubeck's dub.sdl, it depends on mir-blas and mir-lapack. So before you think about getting lubeck to work, you'll need to get those to work. Both of those depend on calling C libraries, you might refer to https://dlang.org/blog/2017/12/05/interfacing-d-with-c-getting-started/ mir-blas depends on the D package cblas, which has headers for blas. It uses blas/cblas as libs, so you'll need to link in a blas library to get it to work. mir-lapack depends on the D package lapack, which has headers for LAPACK. So again, I'm pretty sure you'll need to link in a lapack library to get it to work. The lapack downloads usually contain a blas, though it may not be the most optimized one. The annoying thing is that when you go to the download links for things like lapack for Windows http://icl.cs.utk.edu/lapack-for-windows/ the pre-built libraries require you to either have Visual Studio with Intel Compilers or MinGW and D's support with MinGW isn't all that great. So then what you'd need to do is use CMAKE to compile it with Visual Studio without Intel Compilers. This should work on DMD with -m32mscoff or -m64 and LDC. Also, make sure you link in the library correctly. Visual Studio's linker is different than DMD's when compiling 32bit code. I had given up and used WSL at this point rather than compile it myself with CMAKE. Less of a headache.
Re: Tuts/Aritcles: Incrementasl C++-to-D conversion?
On Thursday, 22 February 2018 at 08:43:24 UTC, ketmar wrote: Nick Sabalausky (Abscissa) wrote: [...] from my experience (various codebases up to middle size, mostly C, some C++): fsck the "one module at a time" idea! even in D modules are interwined, and in C and C++ they're even more so. besides, converting tests is tedious, it is much funnier to have something working. so, i'm usually converting alot of code, up to the whole codebase. it is not fun when compler spits 100500 errors, but when it finally stops... oh, joy! trick: use 'sed' (or your favorite regexp search-and-replace tool) alot. basically, before HDD crash i almost had a set of scripts that does 80-90 percents of work translating C to D with sed. ;-) then use editor with "jump to error line" support, and simply compile your code, fixing errors one by one. tip: try to not rewrite code in any way until it works. i know how tempting it to replace "just this tiny thing, it is so ugly, and in D we have a nice idiom!" NEVAR. this is by far the most important thing to remember (at least for me), so i'll repeat it again: no code modifications until it works! personal memories: C code often using things like `a == [idx]`, where idx can go just past the last array element. it got me when i was doing enet conversion. nasty trick. otherwise, sweat and blood, and patience. These are good starting point so we don't get lost in the process. Still not much exprience doing, but I think these pieces of advice are especially true if the codebase is big or complicated, making it difficult to understand what the C/C++ is doing. When we don't understand the code, re-writing from scratch is not possible.
Re: Function overloading between modules
On Thursday, 22 February 2018 at 21:12:45 UTC, JN wrote:
Is this expected behaviour?
bar.d
---
void foo(string s)
{
}
app.d
---
import std.stdio;
import bar;
void foo(int x)
{
}
void main()
{
foo("hi");
};
===
Error: function app.foo (int x) is not callable using argument
types (string)
https://dlang.org/articles/hijack.html
Help using lubeck on Windows
Help using lubeck on Windows I'd like to experiment with linear algebra in D, and it looks like lubeck is the way to do it right now. However, I'm having a hard time dealing with the CBLAS and LAPACK dependencies. I downloaded the OpenBLAS binaries for Windows (libopenblas.dll), but I am cluless as to what to do with them. I can't find an example of how to link them/what commands to pass to dmd. Any help deeply appreciated.
Re: Game and GC
On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote: What can happen if I create a game using D without worrying with memory management? (using full GC) If you do not worry about memory management at all, it will probably lead to a need to redesign your game. And that's regardless whether you allocate manually, via GC or using reference counting. You should laways make sure you do not have to continuously allocate in a tight loop. By tight I mean somthing thats executed hundreds or thousands of times per second. I do not mean that you should not allocate there, but make sure you can easily move the allocation out such a loop if necessary. GC is most likely a good option, as others have said. It does use more memory than RC or manual management, and leads to short pauses, but is almost as fast as manual management on average. You can: 1: Time the garbage collecions manually so that they happen when responsiveness isn't important. It's likely something like 100ms so even a short such moment will do. For example, when a racing car comes to stop or gets airborne, so that input wouldn't matter anyway. 2: If you have long intervals without such pauses, you can recycle the all the memory you have freed to make sure the program does not accumulate so much that it needs to collect. This is hard, so I recommend it only if 1. isn't feasible or you want to challege yourself. If neither of these are possible, or you think your game will be at limits of the RAM capacity no matter the optimizations (shouldn't happen for an indie game), then you should consider avoiding garbage collection from get-go.
Re: Game and GC
On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote: Hi, I'm new to language and games. Many people say that GC is bad and can slow down your project in some moments. What can happen if I create a game using D without worrying with memory management? (using full GC) Most people who say GC isn't suitable for games are overreacting. D gives you some ways to avoid GC in many cases. People make games in languages like Java, where you can't avoid GC for even the smallest allocations. Especially for 2D games, which just don't have much going on on the screen, you won't be bothered by GC. Even for 3D, as long as you're not making the next Call of Duty, GC shouldn't be a blocker for you. However, you might want to avoid too many allocations, just as you'd do in any other GC language (and non-GC ones too actually). For example, when doing particle emitters, allocating thousands of particles per frame is a bad idea, you'd rather want to use an object pool pattern ( http://www.gameprogrammingpatterns.com/object-pool.html ) - for example preallocate an array of 1000 particles, and when a particle dies, instead of allocating a new one, just reset the values of the one that died with the new one.
