Re: Broken TLS?
On 07/28/2016 12:38 AM, Dechcaudron wrote: Giving my 20 votes to the issue (are votes even taken into account?). At least now I know the source of attribute-enforcements breakdown is basically delegate management. That should help me out enough so I don't have this issue anymore. Thanks a bunch. Can I get your votes on that issue? As far as I know, no one cares much about votes. I'm not going to bother with them. This being a pretty serious accepts-invalid bug, it needs fixing regardless of votes. And unfortunately there are even more important/urgent bugs. There are 37 open dmd regressions [1], and 158 open wrong-code bugs [2]. Maybe not all of them are more important than the bug at hand, but a good bunch probably are. If voting did anything, I'd put everything into issues 15862 [3] and 16292 [4]. 15862 is a ridiculous wrong-code bug with pure nothrow functions. 16292 is a rejects-valid regression that is a blocking a toy project of mine (already has a pull request). [1] https://issues.dlang.org/buglist.cgi?bug_severity=regression=dmd_id=209764_format=advanced=--- [2] https://issues.dlang.org/buglist.cgi?component=dmd=wrong-code_type=allwords_id=209765_format=advanced=--- [3] https://issues.dlang.org/show_bug.cgi?id=15862 [4] https://issues.dlang.org/show_bug.cgi?id=16292
Re: Anybody use FreeImage on Linux with D?
On Wednesday, 27 July 2016 at 23:59:15 UTC, WhatMeWorry wrote:
I've been stumped for several days trying to resolve this run
time error. I'm pretty new with Linux. No problem on Windows.
DerelictFI.load("/home/generic/MySharedLibraries/libfreeimage.so");
before DerelictFI.load
derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-2.0.6/source/derelict/util/exception.d(35):
Failed to load symbol FreeImage_JPEGTransform from shared library
/home/generic/MySharedLibraries/libfreeimage.so
Here's what my shared library looks like. 3.17.0 should be the
latest.
(dmd-2.071.0)generic@generic-ThinkCentre-M93p:~/MySharedLibraries$ ls -al
libfreeimage*
-rw-r--r-- 1 generic generic 731208 Mar 9 02:54
libfreeimage-3.17.0.so
lrwxrwxrwx 1 generic generic 17 Jul 22 21:11
libfreeimage.so -> libfreeimage.so.3
lrwxrwxrwx 1 generic generic 22 Jul 22 21:11
libfreeimage.so.3 -> libfreeimage-3.17.0.so
Google showed me [1], so if you are on Fedora that's likely the
issue. Regardless, if this is a function you aren't using, you
can use Selective Symbol Loading [2] to ignore it. Otherwise,
you'll have to build a custom FreeImage binary that includes it.
[1]
https://gitlab.alelec.net/corona/mingw-packages/blob/001d5085ebb99241004caef02db9fbd3d66a2a83/mingw-w64-FreeImage/FreeImage-3.16.0_disable-some-plugins.patch
[2] http://derelictorg.github.io/using/fail.html
Anybody use FreeImage on Linux with D?
I've been stumped for several days trying to resolve this run
time error. I'm pretty new with Linux. No problem on Windows.
DerelictFI.load("/home/generic/MySharedLibraries/libfreeimage.so");
before DerelictFI.load
derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-2.0.6/source/derelict/util/exception.d(35):
Failed to load symbol FreeImage_JPEGTransform from shared library
/home/generic/MySharedLibraries/libfreeimage.so
Here's what my shared library looks like. 3.17.0 should be the
latest.
(dmd-2.071.0)generic@generic-ThinkCentre-M93p:~/MySharedLibraries$ ls -al
libfreeimage*
-rw-r--r-- 1 generic generic 731208 Mar 9 02:54
libfreeimage-3.17.0.so
lrwxrwxrwx 1 generic generic 17 Jul 22 21:11 libfreeimage.so
-> libfreeimage.so.3
lrwxrwxrwx 1 generic generic 22 Jul 22 21:11
libfreeimage.so.3 -> libfreeimage-3.17.0.so
Thanks.
Autodecode in the wild and An Awful Hack to std.regex
Don't you just hate it when you google a problem and find a post
from yourself asking the same question?
In 2013 I ran into the UTF8 invalid char autodecode UTFException,
and the answer then was "use std.encoding.sanitize" and my
opinion looking at the implementation, was then, as is now... Eww!
Since then, I'm glad to see Walter Bright agrees that autodecode
is problematic.
http://forum.dlang.org/thread/nh2o9i$hr0$1...@digitalmars.com
After wading through 46 pages of that, and Jack Stouffers handy
blog entry and the longish discussion thread on it...
https://forum.dlang.org/post/eozguhavggchzzruz...@forum.dlang.org
Maybe I missed something.
What am I supposed to do here in 2016?
I was happily churning through 25 gigabytes of data with
foreach( line; File( file).byLine()) {
auto c = line.matchFirst( myRegex);
.
.
When I hit an invalid codepoint...Again.
What is an efficient (elegant) solution?
An inelegant solution was to hack into the point that throws the
exception and "Do It Right" (for various values of Right)
diff -u /usr/include/dmd/phobos/std/regex/internal/ir.d{~,}
--- /usr/include/dmd/phobos/std/regex/internal/ir.d~ 2015-12-03
14:41:31.0 +1300
+++ /usr/include/dmd/phobos/std/regex/internal/ir.d 2016-07-28
11:04:55.525480585 +1200
@@ -591,7 +591,7 @@
pos = _index;
if(_index == _origin.length)
return false;
-res = std.utf.decode(_origin, _index);
+res = std.utf.decode!(UseReplacementDchar.yes)(_origin,
_index);
return true;
}
@property bool atEnd(){
That "Works For Me".
But it vaguely feels to me that that template parameter needs to
be trickled all the way up the regex engine.
Re: Broken TLS?
On Wednesday, 27 July 2016 at 20:54:00 UTC, ag0aep6g wrote: Looks pretty bad. There's an open issue on this: https://issues.dlang.org/show_bug.cgi?id=16095 Giving my 20 votes to the issue (are votes even taken into account?). At least now I know the source of attribute-enforcements breakdown is basically delegate management. That should help me out enough so I don't have this issue anymore. Thanks a bunch. Can I get your votes on that issue?
Re: Broken TLS?
On 07/27/2016 09:19 PM, Dechcaudron wrote:
struct Foo
{
[...]
void ping() shared
{
[...]
}
void fire()
{
spawn();
}
void explode() shared
{
ping();
}
}
void main()
{
auto a = Foo(1, 2);
a.fire();
thread_joinAll();
}
[...]
Is there anything I'm doing wrong? I won't lie, data sharing is the only
thing about D I don't find quite usable yet. Can anybody help me out on
this?
I think the program should not compile. You can't call a shared method
on an unshared struct/class, so you shouldn't be able to take make a
delegate of it and call that.
Reduced code:
struct Foo
{
void ping() shared {}
}
void main()
{
Foo a;
// a.ping(); // rejected
()(); // accepted
}
We can also break immutable/const with this:
struct Foo
{
int x = 0;
void ping() { x = 1; }
}
void main()
{
immutable Foo a;
// a.ping(); // rejected
()(); // accepted
assert(a.x == 0); // fails
}
Looks pretty bad. There's an open issue on this:
https://issues.dlang.org/show_bug.cgi?id=16095
Re: Why D isn't the next "big thing" already
On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote: why it isn't the "big thing" already. 1. Less easy to explain A big selling point is that D is good in all directions, and stupidly easy to apply in many situations. That is a lot harder to explain that a simple value proposal like "let's pretend we solved multithreading!" or "let's pretend we solved bugs!". Competitors concentrate their communications on one or two problems to be solved. D is more of an enabler thing, so many people who eg. don't know what meta-programming allows don't miss it in day-to-day operations. 2. Social Proof I would wager that in large part the D community is vaccinated against taking decisions by social proof alone. But we need ever more stories like "that rich/trendy company is making loads of money with D".
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 16:26:47 UTC, Seb wrote: My personal opinion is that the two biggest problems are 1) it has no unique selling point (USP): I don't necessarily agree. I think that D's USPs as seen externally are simplified and powerful metaprogramming abilities, and being a better or "cleaned-up" C++. Internally we all know that D has many USPs.
Broken TLS?
I keep getting data from within a struct shared across threads
for apparently no reason: the code is the following:
import std.stdio;
import std.concurrency;
import core.thread : Thread, thread_joinAll;
struct Foo
{
int a;
int b;
this(int a, int b)
{
this.a = a;
this.b = b;
writefln("Constructor -> a: %s, b: %s, is %s, : %s,
this: %s, Thread: %s",
this.a, this.b, , , ,
Thread.getThis.id);
}
~this()
{
writefln("Final values were a:%s, b:%s", a, b);
}
void ping() shared
{
import core.time: dur;
writefln("a: %s, b: %s, : %s, : %s, this: %s, Thread:
%s",
a, b, , , , Thread.getThis.id);
a = 0;
b = 0;
}
void fire()
{
spawn();
}
void explode() shared
{
ping();
}
}
void main()
{
auto a = Foo(1, 2);
a.fire();
thread_joinAll();
}
What I get on screen is the following:
Constructor -> a: 1, b: 2, is 7FFD5D9E3928, : 7FFD5D9E392C,
this: 7FFD5D9E3928, Thread: 139774191032448
a: 1, b: 2, : 7FFD5D9E3928, : 7FFD5D9E392C, this:
7FFD5D9E3928, Thread: 139774178481920
Final values were a:0, b:0
So effectively, the thread spawned does have access to the
original struct and is able to modify it.
Is there anything I'm doing wrong? I won't lie, data sharing is
the only thing about D I don't find quite usable yet. Can anybody
help me out on this?
Re: randomIO, std.file, core.stdc.stdio
On 07/27/2016 06:46 AM, Rene Zwanenburg via Digitalmars-d-learn wrote: On Wednesday, 27 July 2016 at 02:20:57 UTC, Charles Hixson wrote: O, dear. It was sounding like such an excellent approach until this last paragraph, but growing the file is going to be one of the common operations. (Certainly at first.) (...) So I'm probably better off sticking to using a seek based i/o system. Not necessarily. The usual approach is to over-allocate your file so you don't need to grow it that often. This is the exact same strategy used by D's dynamic arrays and grow-able array-backed lists in other languages - the difference between list length and capacity. There is no built-in support for this in std.mmfile afaik. But it's not hard to do yourself. Well, that would mean I didn't need to reopen the file so often, but that sure wouldn't mean I wouldn't need to re-open the file. And it would add considerable complexity. Possibly that would be an optimal approach once the data was mainly collected, but I won't want to re-write this bit at that point.
Re: Array of const objects with indirections and std.algorithm.copy
On 07/27/2016 04:51 AM, drug wrote:
> I have the following:
>
> ```
> struct Foo
> {
> int[] i;
>
> this(int[] i)
> {
> this.i = i.dup;
> }
>
> ref Foo opAssign(ref const(this) other)
> {
> i = other.i.dup;
>
> return this;
> }
> }
You're defining the assignment from const to non-const. It could have
relied on .dup or something else. The compiler cannot know the
equivalent for the copy operation.
> const(Foo)[] cfoo;
> ```
>
> I need to copy it:
>
> ```
> Foo[] foo;
>
> cfoo.copy(foo); // fails to compile because phobos in case of array uses
> // array specialization and this specialization fails
> // see
That makes sense to me. Otherwise we wouldn't be observing const-ness of
the elements: Mutate the original through the copy...
>
https://github.com/dlang/phobos/blob/v2.071.1/std/algorithm/mutation.d#L333
> ```
>
> but it works:
> ```
> foreach(ref src, ref dest; lockstep(cfoo, foo))
> dest = src;
Because the programmer said it's safe to do so. :)
> // return true
> pragma(msg, __traits(compiles, { typeof(foo).init[] =
> typeof(cfoo).init[]; } ))
(Unrelated, I've just learned that pragma() does not require a
semicolon. Ok... :) )
Well, that's interesting. I guess it means null = null, which does not
compile. I think it's a bug that the above produces true.
However, I would write that __traits(compiles) in a more straightforward
way. (You're creating a lambda there, which does not have anything to do
with the core of the problem here.) So, the following produces false, false:
pragma(msg, __traits(compiles, [ typeof(foo)() ] = [ typeof(cfoo)()
]));
pragma(msg, __traits(compiles, foo = cfoo));
Yeah, those look more straightforward to me at least for this problem.
Ali
Re: How to search for an enum by values and why enum items aren't unique
On 07/27/2016 08:42 AM, stunaep wrote:
On Wednesday, 27 July 2016 at 15:32:59 UTC, Meta wrote:
On Wednesday, 27 July 2016 at 13:59:54 UTC, stunaep wrote:
So how would I make a function that takes an enum and an id as a
parameter and returns a member in the enum? I tried for quite some
time to do this but it wont let me pass Test as a parameter unless I
use templates. I finally came up with this but it wont let me return
null when there's nothing found
E findEnumMember(E)(int id) if (is(E == enum)) {
auto found = [EnumMembers!E].find!(a => a.id == id)();
if(!found.empty)
return found.front;
else
...What do I return? null gives error
}
If you're going to do it like this your only real options are to
return a Nullable!E or throw an exception if the id isn't found.
I tried Nullable!E earlier and it didnt work.
import std.traits;
import std.algorithm;
import std.array;
import std.typecons;
Nullable!E findEnumMember(E)(int id) if (is(E == enum)) {
auto found = [EnumMembers!E].find!(a => a.id == id)();
if(!found.empty)
return Nullable!E(found.front);
else
return Nullable!E();
}
struct S {
int id;
}
enum MyEnum : S {
x = S(42),
invalid = S()// Useful for the other alternative
}
void main() {
auto a = findEnumMember!MyEnum(42);
assert(!a.isNull);
auto b = findEnumMember!MyEnum(7);
assert(b.isNull);
}
I dont need it to be done
like this, it just has to be done someway. I'm asking for help because
that's the only way I could think of.
Another alternative is to require that the enum has a special sentinel:
else
return E.invalid;
Ali
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 16:26:47 UTC, Seb wrote: On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote: Hi guys, I'm using D since a few month now and I was wondering why people don't jump onto it that much and why it isn't the "big thing" already. Everybody is into javascript nowadays, but IMO even for doing web I found Vibe.d more interesting and efficient than node.js for example. I agree that you have to be pragmatic and choose the right tools for the right jobs but I would be interested to have other opinion on thoses questions. My personal opinion is that the two biggest problems are 1) it has no unique selling point (USP): Rust - memory-safety, Go/NodeJS - web app, Python/Julia - scientific computing, R - statistics, Matlab/Mathematica/Octave - numerical programming, Haskell - pure functional, C - kernels, controllers, embedded While the Areas of D Usage (https://dlang.org/areas-of-d-usage.html) is just a brief overview, D can compete with all of these areas. 2) It has no big player with money behind it. Rust (Mozilla), Go (Google), NodeJs (Joyent), ... - having dedicated resources helps a lot to let a project takeoff. That being said it's an awesome language that can rule them all, adoption is rising slowly, but steadily & hopefully with the D Foundation being a non-profit organization real money (http://forum.dlang.org/post/qaskprdxmshpabara...@forum.dlang.org) flows in. I personally don't think having Corp sponsorship will all of sudden bring more ppl in. I think it would be good to work on getting libraries to work with vibe might be a good way to bring interest/development. I know vibe still needs work but the overall system isn't bad but its still a hassle to use w/ a DB in some instances.I also don't believe in the "next big thing" it's hard to compete w/ something like JS and node picked up mainly because its javascript. If u want D to pick up in the web arena just start some projects and post about them... Make youtube videos or whatever. ppl aren't gonna pick it up if all they do is come to the D forums and see a ton of flame fests. Need more positive examples of the language... IDK if Rust is necessarily blowing up in usage I know Go has alot of steam but I would say that Docker may be the cause more than just saying its Google. Also what about things like Hadoop or Kafka. If D had things like this it would also pick up more traction. There is a strong community and it tends to spend too much time on the forums complaining about A or B vs. doing things to improve exposure. Maybe more organization for community projects would be good. I'd say one thing that could be improved is organization within the community. Im not talking about D leadership but just community. I've seen a couple jobs around trying to use Elixir w/ Elm on the front end. There are ppl out there willing to try new things...
Re: Why D isn't the next "big thing" already
On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote: Hi guys, I'm using D since a few month now and I was wondering why people don't jump onto it that much and why it isn't the "big thing" already. Everybody is into javascript nowadays, but IMO even for doing web I found Vibe.d more interesting and efficient than node.js for example. I agree that you have to be pragmatic and choose the right tools for the right jobs but I would be interested to have other opinion on thoses questions. My personal opinion is that the two biggest problems are 1) it has no unique selling point (USP): Rust - memory-safety, Go/NodeJS - web app, Python/Julia - scientific computing, R - statistics, Matlab/Mathematica/Octave - numerical programming, Haskell - pure functional, C - kernels, controllers, embedded While the Areas of D Usage (https://dlang.org/areas-of-d-usage.html) is just a brief overview, D can compete with all of these areas. 2) It has no big player with money behind it. Rust (Mozilla), Go (Google), NodeJs (Joyent), ... - having dedicated resources helps a lot to let a project takeoff. That being said it's an awesome language that can rule them all, adoption is rising slowly, but steadily & hopefully with the D Foundation being a non-profit organization real money (http://forum.dlang.org/post/qaskprdxmshpabara...@forum.dlang.org) flows in.
Re: Check of point inside/outside polygon
On Wednesday, 27 July 2016 at 14:56:13 UTC, Suliman wrote: On Wednesday, 27 July 2016 at 12:47:14 UTC, chmike wrote: On Wednesday, 27 July 2016 at 09:39:18 UTC, Suliman wrote: clip Sorry, its my issue I am thinging about polygons, but for me would be enought points. The problem is next. I am writhing geo portal where user can draw shape. I need to get users images that user shape cross. But as temporal solution it would be enough to detect if image central point inside this polygon (I know its coordinates). I can do its on DB level, but I would like to use SQLite that do bot have geometry support. So i am looking for any solution. I can use gdal but its _very_ heavy So when you say you want polygon intersection, is one of the polygons you are interested in the shape of the images (ie. roughly a rectangle)? If this is the case then you can likely just take the bounding rectangle (easily calculated) of your polygon and check if that intersects the bounding rectangle for the the image and that should work 95% of the time.
Re: How to search for an enum by values and why enum items aren't unique
On Wednesday, 27 July 2016 at 15:32:59 UTC, Meta wrote:
On Wednesday, 27 July 2016 at 13:59:54 UTC, stunaep wrote:
So how would I make a function that takes an enum and an id as
a parameter and returns a member in the enum? I tried for
quite some time to do this but it wont let me pass Test as a
parameter unless I use templates. I finally came up with this
but it wont let me return null when there's nothing found
E findEnumMember(E)(int id) if (is(E == enum)) {
auto found = [EnumMembers!E].find!(a => a.id == id)();
if(!found.empty)
return found.front;
else
...What do I return? null gives error
}
If you're going to do it like this your only real options are
to return a Nullable!E or throw an exception if the id isn't
found.
I tried Nullable!E earlier and it didnt work. I dont need it to
be done like this, it just has to be done someway. I'm asking for
help because that's the only way I could think of.
Re: How to search for an enum by values and why enum items aren't unique
On Wednesday, 27 July 2016 at 13:59:54 UTC, stunaep wrote:
So how would I make a function that takes an enum and an id as
a parameter and returns a member in the enum? I tried for quite
some time to do this but it wont let me pass Test as a
parameter unless I use templates. I finally came up with this
but it wont let me return null when there's nothing found
E findEnumMember(E)(int id) if (is(E == enum)) {
auto found = [EnumMembers!E].find!(a => a.id == id)();
if(!found.empty)
return found.front;
else
...What do I return? null gives error
}
If you're going to do it like this your only real options are to
return a Nullable!E or throw an exception if the id isn't found.
Re: Check of point inside/outside polygon
On Wednesday, 27 July 2016 at 12:47:14 UTC, chmike wrote: On Wednesday, 27 July 2016 at 09:39:18 UTC, Suliman wrote: ... Big thanks! Ehm... Now I should add iteration on array of points in first and second polygon? If it's not hard for you could you show how it should look please. Sorry, I may have misunderstood the initial problem. You were asking how to test if a point is inside a polygon. Now you are referring to two polygons. This sound different. Iterating on segments of a polygon is not so difficult and is highly dependent of the data structure you use to represent points, segments and polygons. This really looks like an assignment or a D learning exercise. What do you need this for ? Do you have the data structures already defined ? Sorry, its my issue I am thinging about polygons, but for me would be enought points. The problem is next. I am writhing geo portal where user can draw shape. I need to get users images that user shape cross. But as temporal solution it would be enough to detect if image central point inside this polygon (I know its coordinates). I can do its on DB level, but I would like to use SQLite that do bot have geometry support. So i am looking for any solution. I can use gdal but its _very_ heavy
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 10:17:57 UTC, NX wrote: On Wednesday, 27 July 2016 at 09:28:49 UTC, chmike wrote: 4. Web server && IO performance (see: https://www.techempower.com/benchmarks or https://github.com/nanoant/WebFrameworkBenchmark). Please, these are terribly outdated benchmarks. There was a recent bug causing Vibe.D to not scale to multiple cores at all which has been fixed. Yes, you are right. It's not easy to determine the version of vibe.d used for techempower. From this link it seam that version 0.7.19 of vibe.d was used Oo unless the Readme is simply outdated. https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/D/vibed For the other one it's vibe v0.7.26 which is more recent. The performance is still low.
Re: How to search for an enum by values and why enum items aren't unique
On Wednesday, 20 July 2016 at 05:45:21 UTC, Jonathan M Davis
wrote:
On Wednesday, July 20, 2016 04:03:23 stunaep via
Digitalmars-d-learn wrote:
How can I search for an enum by its values? For example I have
>struct TestTraits {
>
> int value1;
> string value2;
>
>}
>
>enum Test : TestTraits {
>
> TEST = TestTraits(1, "test1"),
> TESTING = TestTraits(5, "test5")
>
>}
and I have the int 5 and need to find TESTING with it.
In java I would create a SearchableEnum interface, make all
searchable enums implement it and use this method to find them.
>public static T find(T[] vals, int
>id) {
>
> for (T val : vals) {
>
> if (id == val.getId()) {
>
> return val;
>
> }
>
> }
> return null;
>
>}
But the way enums work in D doesn't seem to permit this.
If you want the list of members in an enum, then use
std.traits.EnumMembers and you'll get a compile-time list of
them. It can be made into a runtime list by being put into an
array literal.
For instance, if we take std.datetime.Month, we can look for
the enum with the value 10 in it like so.
auto found = [EnumMembers!Month].find(10);
assert(found = [Month.oct, Month.nov, Month.dec]);
So, if you had your TestTraits struct as the type for an enum,
you could do something like
auto found = [EnumMembers!TestTraits].find!(a => a.value1 ==
5)();
if(found.empty)
{
// there is no TestTraits which matches
}
else
{
// found.front is the match
}
And why on earth are different enum items with the same values
equal to each other? Say I have an enum called DrawableShape
Because they have the same value. The fact that they're enums
doesn't change how they're compared. That's determined by what
type they are. All you're really getting with an enum is a list
of named constants that are grouped together which implicitly
convert to their base type but which are not converted to
implicitly from their base type. The only stuff that's going to
treat an enum member differently from any other value of that
type is something that specifically operates on enums - e.g. by
taking the enum type explicitly, or because it has is(T ==
enum) and does something different for enums (quite a few
traits do that in std.traits), or because it uses a final
switch. Most code is just going to treat them like any other
value of the enum's base type. They aren't magically treated as
unique in some way just because they're in an enum.
- Jonathan M Davis
So how would I make a function that takes an enum and an id as a
parameter and returns a member in the enum? I tried for quite
some time to do this but it wont let me pass Test as a parameter
unless I use templates. I finally came up with this but it wont
let me return null when there's nothing found
E findEnumMember(E)(int id) if (is(E == enum)) {
auto found = [EnumMembers!E].find!(a => a.id == id)();
if(!found.empty)
return found.front;
else
...What do I return? null gives error
}
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran with rdmd. However, the script needs to know it's own
path. The original batch script uses the %~dp0 variable for
this, but I'm at a loss on how to do this in D. Since rdmd
compiles the executable to the %TEMP% directory, thisExePath
won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
For others who may see this thread, the __FULL_FILE_PATH__
special trait was added to the dmd compiler with this PR:
https://github.com/dlang/dmd/pull/5959
At the time of this post, the latest released version of D is
2.071.1, so this trait should be available on any release after
that.
Re: randomIO, std.file, core.stdc.stdio
On Wednesday, 27 July 2016 at 02:20:57 UTC, Charles Hixson wrote: O, dear. It was sounding like such an excellent approach until this last paragraph, but growing the file is going to be one of the common operations. (Certainly at first.) (...) So I'm probably better off sticking to using a seek based i/o system. Not necessarily. The usual approach is to over-allocate your file so you don't need to grow it that often. This is the exact same strategy used by D's dynamic arrays and grow-able array-backed lists in other languages - the difference between list length and capacity. There is no built-in support for this in std.mmfile afaik. But it's not hard to do yourself.
Re: Check of point inside/outside polygon
On Wednesday, 27 July 2016 at 09:39:18 UTC, Suliman wrote:
On Wednesday, 27 July 2016 at 08:40:15 UTC, chmike wrote:
The algorithm is to draw a horizontal (or vertical) half line
starting at your point and count the number of polygon edges
crossed by the line. If that number is even, the point is
outside the polygon, if it's odd, the point is inside.
Let (x,y) be the point to test and (x1,y1)(x2,y2) the end
points on each segment. Let n be the number of crossing that
you initialize to 0. (x1,y1)(x2,y2) are also the corners of
the rectangle enclosing the segment.
You then have to examine each segment one after the other. The
nice thing is that there are only two cases to consider.
1. When the point is on the left side of the rectangle
enclosing the segment.
2. When the point is inside the rectangle enclosing
if (y1 <= y2)
{
if ((y1 <= y) && (y2 >= y))
{
if ((x1 < x) && (x2 < x))
{
// case 1 : point on the left of the rectangle
++n;
}
else if (((x1 <= x) && (x2 >= x)) || ((x1 >= x) && (x2
<= x)))
{
// case 2 : point is inside of the rectangle
if ((x2 - x1)*(y - y1) >= (y2 - y1)*(x - x1))
++n; // Increment n because point is on the
segment or on its left
}
}
}
else
{
if ((y1 >= y) && (y2 <= y))
{
if ((x1 < x) && (x2 < x))
{
// case 1 : point on the left of the rectangle
++n;
}
else if (((x1 <= x) && (x2 >= x)) || ((x1 => x) && (x2
<= x)))
{
// case 2 : point is inside of the rectangle
if ((x2 - x1)*(y - y2) >= (y1 - y2)*(x - x1))
++n; // Increment n because point is on the
segment or on its left
}
}
}
This algorithm is very fast.
I didn't tested the above code. You might have to massage it a
bit for corner cases. It should give you a good push to start.
Big thanks!
Ehm... Now I should add iteration on array of points in first
and second polygon? If it's not hard for you could you show how
it should look please.
Easiest solution (if you don't care about performance) is to
pairwise compare every segment of both polygons to see if they
intersect, and if that fails, then run point-in-polygon algorithm
with one vertex from each polygon and the other (catches the case
where one polygon is entirely contained within the other).
Now you have the point in polygon algorithm (kindly provided by
chmike) and testing for segment intersection is a basic primitive
geometric operation, so there are lots of examples on the web.
You should certainly be able to find working C code for this
without much trouble.
Re: Check of point inside/outside polygon
On Wednesday, 27 July 2016 at 09:39:18 UTC, Suliman wrote: ... Big thanks! Ehm... Now I should add iteration on array of points in first and second polygon? If it's not hard for you could you show how it should look please. Sorry, I may have misunderstood the initial problem. You were asking how to test if a point is inside a polygon. Now you are referring to two polygons. This sound different. Iterating on segments of a polygon is not so difficult and is highly dependent of the data structure you use to represent points, segments and polygons. This really looks like an assignment or a D learning exercise. What do you need this for ? Do you have the data structures already defined ?
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 11:11:56 UTC, llaine wrote: On Wednesday, 27 July 2016 at 10:42:50 UTC, lkfsdg wrote: Also I predict that the more it'll get popular the less it will attract hobbyist. I did't realized at the beginning (I've discovered D in 2012 then started to learn more seriously in 2014) but Alexandrescu clairly aims at a professional usage so it'll become less and less fun. What do you mean by that ? It should be clear so let's rephrase: I think that hobbyists will be less and less attracted by D because its professionalization. But you shouldn't attach any importance to this idea. I might be wrong, it's just that if, let's say, in five years I observe that this is true, I will be able to say "I knew it" without being biased (retrospective bias) because the idea is clearly stated. ;)
Array of const objects with indirections and std.algorithm.copy
I have the following:
```
struct Foo
{
int[] i;
this(int[] i)
{
this.i = i.dup;
}
ref Foo opAssign(ref const(this) other)
{
i = other.i.dup;
return this;
}
}
const(Foo)[] cfoo;
```
I need to copy it:
```
Foo[] foo;
cfoo.copy(foo); // fails to compile because phobos in case of array uses
// array specialization and this specialization fails
// see
https://github.com/dlang/phobos/blob/v2.071.1/std/algorithm/mutation.d#L333
```
but it works:
```
foreach(ref src, ref dest; lockstep(cfoo, foo))
dest = src;
```
In my opinion the possible decision is disabling the array
specialization if the arrays can't be low-level copied. And the question
raises here - why `areCopyCompatibleArrays` doesn't work in this case? I
found that
```
// return true
pragma(msg, __traits(compiles, { typeof(foo).init[] =
typeof(cfoo).init[]; } ))
// return false
pragma(msg, __traits(compiles, { foo[] = cfoo[]; } ))
```
The question is - shouldn't `areCopyCompatibleArrays` be modified
according code above to use array specialization where it is appropriate
and allow to copy arrays by elements when it is needed?
The full code is here https://dpaste.dzfl.pl/5e13e183a006
Re: Why D isn't the next "big thing" already
On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote: Hi guys, I'm using D since a few month now and I was wondering why people don't jump onto it that much and why it isn't the "big thing" already. Because languages don't become big things. Good solutions to particular problems become big things, but D is a very good language and nothing more. So if that is your criteria for choosing a language, you might want to use something else. D will go the route of continual improvement and increased adoption. As more and more people use it for small projects, the ecosystem will improve, and it will begin to be adopted for bigger projects.
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 10:42:50 UTC, lkfsdg wrote: Also I predict that the more it'll get popular the less it will attract hobbyist. I did't realized at the beginning (I've discovered D in 2012 then started to learn more seriously in 2014) but Alexandrescu clairly aims at a professional usage so it'll become less and less fun. What do you mean by that ?
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 10:39:52 UTC, NX wrote: Lack of production quality tools like? no, "refactoring" and other crap is not "production quality tools", they are only useful to pretend that you are doing something useful, so you will look busy for your boss.
Re: Why D isn't the next "big thing" already
On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote: Hi guys, I'm using D since a few month now and I was wondering why people don't jump onto it that much and why it isn't the "big thing" already. Everybody is into javascript nowadays, but IMO even for doing web I found Vibe.d more interesting and efficient than node.js for example. I agree that you have to be pragmatic and choose the right tools for the right jobs but I would be interested to have other opinion on thoses questions. Seriously, it could take years before D gets really popular and that's normal. Web languages have raised quickly because they were new, they weren't fighting against anything. D has C, Java and C++ plus the other "new" languages Go, Rust. Also I predict that the more it'll get popular the less it will attract hobbyist. I did't realized at the beginning (I've discovered D in 2012 then started to learn more seriously in 2014) but Alexandrescu clairly aims at a professional usage so it'll become less and less fun.
Re: Why D isn't the next "big thing" already
Lack of production quality tools Lack of good marketing Lack of man power & corporate support Lack of idiomatic D libraries These are pretty much the core of all other negative consequences. Ex: GDC is few versions behind DMD because lack of man power. If only we could break the vicious circle...
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 09:28:49 UTC, chmike wrote: The reason I'm switching to Go is because 3. GC performance (no stop the world hiccups) IIRC, there is a concurrent GC implementation used by sociomantic but it's linux only. (It uses fork() sys call) 4. Web server && IO performance (see: https://www.techempower.com/benchmarks or https://github.com/nanoant/WebFrameworkBenchmark). Please, these are terribly outdated benchmarks. There was a recent bug causing Vibe.D to not scale to multiple cores at all which has been fixed.
Re: Search elemnt in Compile-time Argument List of strings
On 07/26/2016 09:30 PM, ParticlePeter wrote:
So how can I achieve my goal the right way?
Here's one with CTFE:
void processMember(T, ignore...)()
{
import std.algorithm: canFind, filter;
import std.meta: aliasSeqOf;
enum selectedMembers = aliasSeqOf!(
[__traits(allMembers, T)].filter!(m => ![ignore].canFind(m))
);
foreach (member; selectedMembers)
{
/* process member here, generate e.g. setter function as string
mixin */
}
}
Re: Check of point inside/outside polygon
On Wednesday, 27 July 2016 at 08:40:15 UTC, chmike wrote:
The algorithm is to draw a horizontal (or vertical) half line
starting at your point and count the number of polygon edges
crossed by the line. If that number is even, the point is
outside the polygon, if it's odd, the point is inside.
Let (x,y) be the point to test and (x1,y1)(x2,y2) the end
points on each segment. Let n be the number of crossing that
you initialize to 0. (x1,y1)(x2,y2) are also the corners of the
rectangle enclosing the segment.
You then have to examine each segment one after the other. The
nice thing is that there are only two cases to consider.
1. When the point is on the left side of the rectangle
enclosing the segment.
2. When the point is inside the rectangle enclosing
if (y1 <= y2)
{
if ((y1 <= y) && (y2 >= y))
{
if ((x1 < x) && (x2 < x))
{
// case 1 : point on the left of the rectangle
++n;
}
else if (((x1 <= x) && (x2 >= x)) || ((x1 >= x) && (x2
<= x)))
{
// case 2 : point is inside of the rectangle
if ((x2 - x1)*(y - y1) >= (y2 - y1)*(x - x1))
++n; // Increment n because point is on the
segment or on its left
}
}
}
else
{
if ((y1 >= y) && (y2 <= y))
{
if ((x1 < x) && (x2 < x))
{
// case 1 : point on the left of the rectangle
++n;
}
else if (((x1 <= x) && (x2 >= x)) || ((x1 => x) && (x2
<= x)))
{
// case 2 : point is inside of the rectangle
if ((x2 - x1)*(y - y2) >= (y1 - y2)*(x - x1))
++n; // Increment n because point is on the
segment or on its left
}
}
}
This algorithm is very fast.
I didn't tested the above code. You might have to massage it a
bit for corner cases. It should give you a good push to start.
Big thanks!
Ehm... Now I should add iteration on array of points in first and
second polygon? If it's not hard for you could you show how it
should look please.
Re: Why D isn't the next "big thing" already
On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote: Hi guys, I'm using D since a few month now and I was wondering why people don't jump onto it that much and why it isn't the "big thing" already. Everybody is into javascript nowadays, but IMO even for doing web I found Vibe.d more interesting and efficient than node.js for example. I agree that you have to be pragmatic and choose the right tools for the right jobs but I would be interested to have other opinion on those questions. I've been testing D and love many features of the language. But I'm now to switching to Go for my alimentary project. But I prefer D's syntax, ranges and the easiness of generic coding. The reason I'm switching to Go is because 1. there is a much larger community and code base (it's easier to find code snippet, help or programmers) 2. go routines (fibers integrated into the language, plug & play) 3. GC performance (no stop the world hiccups) 4. Web server && IO performance (see: https://www.techempower.com/benchmarks or https://github.com/nanoant/WebFrameworkBenchmark). As a computer scientist I prefer D to Go and see a lot of potential in it. But as a software developer I feel that D still needs maturation to be competitive in a production environment. I guess this is the reason why D doesn't get much traction yet.
Re: Check of point inside/outside polygon
The algorithm is to draw a horizontal (or vertical) half line
starting at your point and count the number of polygon edges
crossed by the line. If that number is even, the point is outside
the polygon, if it's odd, the point is inside.
Let (x,y) be the point to test and (x1,y1)(x2,y2) the end points
on each segment. Let n be the number of crossing that you
initialize to 0. (x1,y1)(x2,y2) are also the corners of the
rectangle enclosing the segment.
You then have to examine each segment one after the other. The
nice thing is that there are only two cases to consider.
1. When the point is on the left side of the rectangle enclosing
the segment.
2. When the point is inside the rectangle enclosing
if (y1 <= y2)
{
if ((y1 <= y) && (y2 >= y))
{
if ((x1 < x) && (x2 < x))
{
// case 1 : point on the left of the rectangle
++n;
}
else if (((x1 <= x) && (x2 >= x)) || ((x1 >= x) && (x2 <=
x)))
{
// case 2 : point is inside of the rectangle
if ((x2 - x1)*(y - y1) >= (y2 - y1)*(x - x1))
++n; // Increment n because point is on the segment
or on its left
}
}
}
else
{
if ((y1 >= y) && (y2 <= y))
{
if ((x1 < x) && (x2 < x))
{
// case 1 : point on the left of the rectangle
++n;
}
else if (((x1 <= x) && (x2 >= x)) || ((x1 => x) && (x2 <=
x)))
{
// case 2 : point is inside of the rectangle
if ((x2 - x1)*(y - y2) >= (y1 - y2)*(x - x1))
++n; // Increment n because point is on the segment
or on its left
}
}
}
This algorithm is very fast.
I didn't tested the above code. You might have to massage it a
bit for corner cases. It should give you a good push to start.
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 00:52:30 UTC, Gorge Jingale wrote: So, you can see D as a sort of dried up waste land desert with a few nice palm trees growing here and there and a few scorpions. C++, say, is a very lush forest with many tree dwelling monkeys. Which environment would you rather use? You're forgetting the spiked stick pits that the lush forest is full of, and also the monkeys are rabid. =)
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 00:52:30 UTC, Gorge Jingale wrote: I think it is because D has some fundamental problems. It is a risk to use software that is not proven to be safe, effective, and easy to use. The fact there are so many bugs(and many are big blockes) in D says something about D, it matters not how fast they are fixed. Which fundamental problems you refer to? I'm curious about thoses, I feel I just scratch the tip of the language so far.
