Can D not reduce template error messages?
Getting N messages for N template parameter variations on a template. void foo(A,B)(); A and B are selected from N different values and all are used. If there is an error in the function then I get N^2 error messages, one for each combination. All the error messages say the same thing except A and B are different. If the error message is several lines then that is multiplied by N^2. Why can't D do a bit of error diagnostics. If the errors pertain to the same template and have every character the sample except the template values then just make a generic message: These are the actual error messages, I did not copy and paste!!! o.d(152): Error: function `foo!(float, float).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, float).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(274): Error: template instance `foo!(float, float)` error instantiating o.d(152): Error: function `foo!(float, int).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, int).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(277): Error: template instance `foo!(float, int)` error instantiating o.d(152): Error: function `foo!(float, int24).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, int24).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(280): Error: template instance `foo!(float, int24)` error instantiating o.d(152): Error: function `foo!(float, short).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, short).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(283): Error: template instance `foo!(float, short)` error instantiating o.d(152): Error: function `foo!(float, byte).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, byte).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(286): Error: template instance `foo!(float, byte)` error instantiating o.d(152): Error: function `foo!(float, ubyte).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, ubyte).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d-mixin-264(289): Error: template instance `foo!(float, ubyte)` error instantiating o.d(152): Error: function `foo!(float, void).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(float, void).bar(string)` is not callable using argument types `(int)` and this is when A is constant! When I allow A to vary then it is squared in number!! It is ridiculous! It all could be simplified: .d-mixin-264(274): Error: template instance `foo!(A, B)` error instantiating o.d(152): Error: function `foo!(A, B).bar(string)` is not callable using argument types `(int)` o.d(152):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` o.d(174): Error: function `foo!(A, B).bar(string)` is not callable using argument types `(int)` o.d(174):cannot pass argument `bufPos` of type `double` to parameter `int x = 0` where A is float, B is ubyte, void, float, etc...
Orange serializer/deserializer
How can I modify the pre serialization and post serialization values? I need to transform some variables that are stored but I would like to do this easily "inline"(would be cool to be able to provide a delegate to do the transformations at the site of definition of the fields). Also, how does orange handle properties? Seems it just deals with fields and ignores all functions(does not use getter and setter of properties). This is valid, of course, just want to make sure. I still need to be able to transform values pre and post though.
Re: Installation on Ubuntu 18.04 is broken
On Friday, 1 June 2018 at 20:07:59 UTC, bachmeier wrote: On Friday, 1 June 2018 at 16:41:21 UTC, bachmeier wrote: I would file a bug, but I don't have time to dig into this now, and it would just sit there with no response for six months anyway. I cannot find a way to get std.net.curl to work with Ubuntu 18.04. Details can be found here: https://forum.dlang.org/thread/bug-1864...@https.issues.dlang.org%2F but that only lets you install the package without having a broken package management system. It resolves nothing wrt actually being able to use curl, which is part of the standard library, and should be expected to work. I tried using the install script, but that leads to this bug https://issues.dlang.org/show_bug.cgi?id=18808 which was filed more than a month ago and still hasn't received a response. This experiment with having a new release every couple of weeks was fun, but can we please be realistic about our resources, and move to a sensible schedule. D is simply not an option in situations that require reliability. And all the various deprecations and language changes that are inserted in these high-frequency releases (changes of arbitrary size can come with little warning in *any* release) make it that much more difficult. I think this was resolved by installing libcurl4-gnutls-dev, removing the existing dmd, and reinstalling. Whatever the problem was, this does not create a good impression. We have to stop releasing so often. No other major language that I've used has problems like this. Your failure is that D is not a major language. It's like saying that "No other dogs I've come across meow, why does this dog meow"? It's a cat stupid!! :0
How are switches optimized
What is the best optimizations that a compiler does to switches
in general and in the D compilers?
A switch can be seen as if statements, or safer, nested if elses.
but surely the cost per case does not grow with depth in the
switch? If one has a switch of N case then the last cost surely
does not cost N times the cost of the first, approximately? This
is the cost when implementing a switch as nested ifs.
Tables can be used to give O(1) cost, are these used in D's
compilers? How are they generally implemented? Hash tables? If
the switch is on an enum of small values is it optimized for a
simple calculating offset table?
switch(e)
{
case E.a:
...
case E.z:
...
}
jmp offset + val(e)
Or, in general a map table can be used
jmp offset + map[e]
Just curious...
Re: On Forum Moderation
On Sunday, 27 May 2018 at 05:30:22 UTC, TheUncivilServant wrote: On Sunday, 27 May 2018 at 04:57:20 UTC, SlimeBag wrote: surely the best form of professional etiquette is to NOT be offended by what others say. as soon as you ignore that etiquette, it's a slippery slope to utlimately controlling others. I agree. One can also argue, that for those who are intent on practisiing 'etiquette', those who are not practicing 'etiquette', become (initially) an irritant (to those intent on practicing 'etiquette'). Eventually, this cultivates into a 'hatred' (of those not practicing 'etiquette'). So, 'etiquette' actually leads to an uncivilised society. The 'victorian era' of Emily Post, was stife with 'etiquette', and is why Freud had so many patients. This is precisely why their are so many problems in the world. So many people believe that the way to achieve some imaginary ideal is to forcibly go that way and just through "banging ones head" enough it will magically materialize. What happens, at least in the long run, in fact is that they do the exact opposite of what they were trying to achieve. You can point to any number of the major social issues and see that they have progressively worsened precisely because of the people supposedly trying to make things better have done this. So society progressively gets worse in many areas and more and more people come out to "fix" things only to dig the hole deeper. Sometimes people just need to be told off, sometimes people need to be shot, some times people need bad thing to happen so that worse things don't. Humans can't control everything and trying only makes things worse. It's built in to the system. The Heisenberg uncertainty principle is built in to everything. It is applicable not just to atoms but things composed of atoms like love(which is a very complex system of atoms), gun rights, education, etc. It's bad enough that humans are pretty clueless about the true complexities of the universe but their ignorance in the very basic concept of balance is what really makes the world the way it is. Westerners tend to be extremely ignorant of balance for some reason.
Re: Getter an lvalue and cannot be modified
On Sunday, 27 May 2018 at 09:28:36 UTC, Mike Franklin wrote:
On Sunday, 27 May 2018 at 09:23:09 UTC, IntegratedDimensions
wrote:
C[] c;
@property C[] get() { return c; }
get ~= something;
errors out, yet
auto q = get;
q ~= something;
is fine.
Why is D thinking that ~= is being applied to get, the
function, rather than what it returns?
Also
When I converted a field in to a property, an AA, it is
returning null rather than being initialized by default. Seems
like properties are broke. I'd expect a property getter to
behave, for all intents and purposes as if it were field. I
shouldn't have to have a temp variable to be able to use it as
such.
You'll probably get your answer and more by reading this:
https://github.com/dlang/DIPs/pull/97
I came across a few posts mentioning this after the fact. It's
been this way since at least 2012 so... It's now may so not sure
how much longer we'll have to wait. That pull seems to have
stalled. So close but so far away ;/
Re: Code repetition
On Sunday, 27 May 2018 at 13:20:08 UTC, Adam D. Ruppe wrote:
On Sunday, 27 May 2018 at 06:47:38 UTC, IntegratedDimensions
wrote:
Putting the code in a template/function/lambda does not work
because of the scopes which will be called when the main
function exists.
I think you might just be using the wrong kind of function.
---
import std.stdio;
// the helper does the setup then calls another function for
specific stuff
void helper(void delegate(ref int) specialized) {
// setup stuff
int x;
scope(exit) writeln("exit ", x);
// specialized stuff abstracted out
specialized(x);
}
void foo() {
helper( (ref x) {
x = 34;
});
}
void main() {
foo();
}
---
Yeah, this should work. Was hoping there was just a simple way to
pull the code out but I guess this provides the best alternative.
Thanks.
Re: General problem I'm having in D with the type system
On Sunday, 27 May 2018 at 21:16:46 UTC, Neia Neutuladh wrote:
On Sunday, 27 May 2018 at 20:50:14 UTC, IntegratedDimensions
wrote:
The only problem where it can leak is when we treat an cat as
an animal then put in dog food in to the animal, which is
valid when cat as treated as an animal, then cast back to cat.
Now cat has dog food, which is invalid.
It sounds like you don't want to have a `food` setter in the
`Animal` base class. Instead, you want setters in each child
class that take the specific type required, and possibly an
abstract getter in the base class. You could use a mixin to
ease the process of defining appropriate food types, and you
could have a method that takes the base `Food` class and does
runtime validation.
You might also change `Animal` to `Animal!(TFood : Food)` and
go from there. You'd likely need to extract another base class
or interface so you can have a collection of arbitrary animals.
The problem with all this is that it is not the correct way. For
N types you have to scale: Animal(Food, Skin, Eyes, ...).
While not having a specific setter in the Animal class does solve
the problem of preventing assignment and sorta solve the problem
by requiring assignment to occur at the proper object it does not
solve the general problem. If we create an animal we should we
able to assign it animal food(rather than tools). In a sense this
goes a bit too far. Remember, a type hierarchy could be much more
complex and we can have types of types which will then all have
to follow these "workarounds" resulting if a very complex mess.
life
domain
kingdom
phylum
class
order
family
genus
species
...
Within each of these types there are specializations
the human species is a type of species in the homo genus, etc.
Now, how can we model such a thing be providing maximum compile
time typing structure?
class life; // Sorta like object, something that can be anything
and contains only the common structure to all things that can be
considered living
class domain : life;
...
class species : genus;
class human : species;
Now, this is all standard. But all types will *use* other types.
Humans will use, for example, tools. So we will have another
complex hierarchy where tools fall somewhere
class tool : object;
class hammer : tool;
so
class human : species
{
tool[] t;
}
Now, suppose we have bob the house builder, a human,
class houseBuilder : humanWorker;
in which we could add a tool to bob
auto bob = new houseBuilder();
bob.tools ~= new hammer();
All fine an dandy!
This is because tool there is not a natural transformation
between human and houseBuilder and tool and hammer. There a
hammer being derived from a tool in no way corresponds to a
houseBuilder being derived from a human. The "uses" in this case
is from types to types and objects to objects (humans use tools
and bob uses a hammer).
For the structure I am talking about, "parallel inheritance"
there is a natural relationship between types to types and types
to types that naturally transform in "parallel".
To understand this we need to think about something that
parallels our taxonomy so that as we inherit through one there is
a *natural* inheritance through the other and a sort of
"correspondence"(the natural transformation) that keeps
everything aligned. Sorta like a ladder where we can only move
up and down but each end of a rung.
Life ->A
Domain ->B
... ->...
Genus->X
Species ->Y
Human->Z
houseBuilder ->_
Now, if your paying attention, Human is actually not part of the
taxonomy above, it is a specialization of Species.
Unfortunately in D we only have one level of typing rather that
types of types. We only have a type. The taxonomy above would be
a type of a type of an object while humans would be a type of
object. So what happens is the different conceptualizations are
conflated. Since types can be treated as sets, this is like
saying that sets of sets are the same as sets. Well, sets of sets
are sets but not all sets are sets of sets, hence they are not
exactly the same(it is inclusion rather than equality).
{1,2,3} is not a set of sets. (although, it is true we can treat
1,2,3 as sets and so we could say it is but but I don't want to
get in to the sets of things that are not sets problem).
So, really what we have is that the taxonomy is precisely this
paralleling that goes on:
Life ->Life
Domain ->Eukaryote
... ->...... ...
Genus->Homo _> ... ...
Species ->Human _> houseBuilder --> bob -->
hammer
So, for example, Eukaryote's have cells that build things and
different ways to class them. Hence "Builders" would have
Re: General problem I'm having in D with the type system
On Sunday, 27 May 2018 at 06:59:43 UTC, Vijay Nayar wrote:
On Sunday, 27 May 2018 at 06:00:30 UTC, IntegratedDimensions
wrote:
The problem description is not very clear, but the catfood
example gives a bit more to work with.
animal -> food
||
vv
cat -> catfood
Of course, I'm not sure how to avoid the problem in D of
animal a = new cat();
a.f = new food()
auto c = cast(cat)a;
Cast operations are generally not guaranteed to preserve type
safety and should be avoided when possible. But if I
understand your description, you have the following relations
and transitions:
animal owns food
catowns catfood
animal may be treated as a cat (hence the casting)
food may be treated as a catfood (hence the casting)
It may be that the inheritance relationship is backwards in
your use case. If "animal" may be treated as a "cat", then the
inheritance should be other other way around, and "animal"
would inherit from "cat".
No, this would make no sense. Inheritance is about
specialization, taking a type and specifying more constraints or
properties to make it more well defined or more specific. Or,
simply, a superset.
What specific kinds of relationships are you trying to model
among what kinds of entities?
I've already mentioned this. It is natural for specializations of
a type to also specialize dependencies. The animal/cat example is
valid.
A animal can be any thing that is an animal that eats any food.
a cat is an animal that is a cat and eats only food that cats eat.
This is true, is it not? cats may eat dog food, it is true, but
cats do not eat any animal food. They do specialize. Cat food may
be less specialized to some in between thing for this specific
case to work but it's only because I used the term cat food
rather than some other more general class.
Animal -> Animal food
Koala -> Koala food
A Koala only eats specific types of food, nothing else. We can
call that Koala food.
As an animal, koala food is still animal food, so casting still
works. It is only the upcasting that can fail. But that is true
in general(we can't cast all animals to Koala's... and similarly
we can't cast all animal food to all Koala food). D's cast will
only enforce one side because he does not have the logic deal
with dependent parallel types.
This is a very natural thing to do. Haskell can handle these
situations just fine. With D, and it's inability to specify the
relationship dependencies, it does not understand that things are
more complex.
Hence we can, in D, put any type of food in Koala in violation of
the natural transformations we want:
(cast(Animal)koala).food = catFood;
This is a violation of the structure but allowable in D due to it
not being informed we cannot do this. If we had some way to
specify the structure then it would result in a runtime
error(possibly compile time if it new koala was a Koala and could
see that we are trying to assign catFood to a KoalaFood type).
auto a = (cast(Animal)koala);
a.food = someFood;
auto k = cast(Koala)a;
k.food =?= someFood; // error
of course, if cast worked using deeper structural logic then
k.food would be null or possibly k would be null(completely
invalid cast).
You have to realize that I am talking about applying constraints
on the type deduction system that do not already exist but that
actually make sense.
If you wanted to model the animal kingdom and made a list of all
the animals and all the food they ate, there would be
relationships. Some animals will eat just about anything while
others will eat only one thing.
AnimalsFoods
......
If you were to model this in using classes you would want some
way to keep some consistency.
If you do
class Animal
{
Food food;
}
class Koala : Animal
{
}
Then Koala allows *any* food... then you have to be careful of
sticking in only koala food! But if we *could* inform the
compiler that we have an additional constraint:
class SmartKoala : Animal
{
KoalaFood : Food food;
}
then SmartKoala will be able to prevent more compile time errors
and enforce the natural inherence relationship that exists
between animals on food.
We can do this with properties on some level
class Animal
{
@property void food(Food food);
}
class SemiSmartKoala : Animal
{
override @property void food(Food food) { if
(!is(typeof(food) == KoalaFood)) throw ... }
}
This, of course, only saves us at runtime and is much more
verbose and is not really naturally constraining dependencies.
Re: General problem I'm having in D with the type system
On Sunday, 27 May 2018 at 18:16:25 UTC, JN wrote: On Sunday, 27 May 2018 at 06:00:30 UTC, IntegratedDimensions wrote: animal a = new cat(); a.f = new food() auto c = cast(cat)a; as now f in cat will be food rather than catfood. I think the problem is in your hierarchy. If Animal can have Food, that means that any animal should be able to accept any food, without knowing what kind of food is this. Cat requiring cat food is a leaky abstraction, the cat shouldn't know nor care what kind of food it gets, as it's an animal and it will eat any food. This is clearly false. A Kola does not eat any type of food, nor does a whale or most animals. While it is just an example, it still applies in general. Natural transformations are fundamental to type theory. The only problem where it can leak is when we treat an cat as an animal then put in dog food in to the animal, which is valid when cat as treated as an animal, then cast back to cat. Now cat has dog food, which is invalid. But I've already pointed out two things about this: 1. The hierarchy is maintained to be non-leaky at runtime(I never down cast). 2. casting can be designed to handle this behavior. When we cast animal to cat then the cast can null dog food since it isn't cat food. No different than if we cast animal to hammer but requires a bit more compiler logic.
Getter an lvalue and cannot be modified
C[] c;
@property C[] get() { return c; }
get ~= something;
errors out, yet
auto q = get;
q ~= something;
is fine.
Why is D thinking that ~= is being applied to get, the function,
rather than what it returns?
Also
When I converted a field in to a property, an AA, it is returning
null rather than being initialized by default. Seems like
properties are broke. I'd expect a property getter to behave, for
all intents and purposes as if it were field. I shouldn't have to
have a temp variable to be able to use it as such.
Re: Code repetition
I guess I should have mentioned that basically this is like a C macro.
Code repetition
I have some code like
void foo()
{
// setup stuff
int x;
scope(exit) something;
//
x = 34;
}
void foon()
{
// setup stuff
int x;
scope(exit) something;
//
}
All the setup stuff is virtually identical in each foo. There are
slight differences such as a return value.
I would like to abstract the code code so that it can be handled
in one place.
I have not found a way to do this in D. Template mixins do not
work because of the arbitrary expressions. Putting the code in a
template/function/lambda does not work because of the scopes
which will be called when the main function exists.
A string mixin is too messy since it treats the code as a string
losing all syntax highlighting, etc.
I'd love to have something like a template mixin where I can just
do
mixin template fooSetup(ret)
{
// setup stuff
int x;
scope(exit) something;
}
and
void foo()
{
fooSetup(3);
}
void foo4()
{
fooSetup(13);
}
and everything behave as it should. I'm guessing this is going to
be impossible to achieve in D?
Re: Friends in D, a new idiom?
On Sunday, 27 May 2018 at 06:24:13 UTC, Vijay Nayar wrote:
On Sunday, 27 May 2018 at 05:25:53 UTC, IntegratedDimensions
wrote:
Re: Friends in D, a new idiom?
In D, there's no exact equivalent to friend, but there are a
few more specialized tools at your disposal. Normally all code
in the same module is essentially a friend, so if the classes
you are dealing with are tightly coupled, they can simply be in
the same module.
Yes, but this is not the case. I have two classes somewhat
related but in different modules so I am looking for a more
general solution. I do not like chunking everything in to the
same module just to get around this type of problem.
For example:
module m;
class C {
// This is still visible in the same module.
// See
https://dlang.org/spec/attribute.html#VisibilityAttribute
private int data;
...
}
class CAccessor {
C _this;
this(C c) {
_this = c;
}
@property void data(int v) {
_this.data = v;
}
...
}
Initially I thought nested classes contained an inherent super
but I guess that is not the case?
Super is for inheritance rather than inner classes. So another
way to tackle your problem using super would be this:
class C {
protected int _data;
@property int data() {
return _data;
}
}
class CAccessor : C {
@property void data(int v) {
_data = v;
}
C toC() {
return this;
}
}
Yeah, but this is a bit bulky. Although maybe UFCS could work
well in this case although one would end up requiring different
names in modules rather than Access or Friend.
I haven't tried it but if UFCS allows a module function to access
the protected member and outside the module the UFCS could be
called. I think this might defeat the usage except I recently saw
that UFCS can be called with = so they can emulate setters, so it
might work well(until that syntax is depreciated).
I also imagine that one could enhance this so that write
access could also be allowed by certain types.
The 'package' visibility attribute can also be given a
parameter if you need to limit access only to certain module.
Yeah, maybe using packages is the best way to go. The modules I'm
using are related so they could be used in a package. Doesn't
help with the general case though.
Any ideas about this type of pattern, how to make it better,
already exists etc?
You might be looking for the "Builder Pattern" which uses a
separate object to construct and modify objects, and then it
creates a read-only object with those values upon request.
I'm looking for something lightweight and direct. It is not for
total encapsulation control but to simply provide an extra level
of indirection for write access to make the object look read only
to those that directly use it.
Basically I have another class outside the module that needs to
write to a variable in side an object to set it up, from then on
it is read only. It can't be done at construction. Maybe their
will be one or two other times that it will need to change but I
don't see why I should have to expose it for anyone nor create a
huge layer of complexity to allow for a single access. The method
I gave works fine for this type of behavior and the UFCS probably
will even be easier if it works.
General problem I'm having in D with the type system
(see my other most recent post for disclaimer)
My designs generally work like this:
Main Type uses Subservient types
A a
B b
C c
where C : B : A, c : b : a.
In the usage I must also keep consistent the use of c in C, b in
B, a in A. There is little if nothing in the type system that
allows me to specify and force this type of relationship.
Although there is some covariant functions that do help such as
overriding properties with covariance.
class a;
class b : a;
class A { a x; @property a X() { return x; } @property void X(a
v) { x = v; } }
class _B { b x; @property b X() { return x; } @property void X(a
v) { x = v; } }
class B : A { @property b X() { return cast(b)x; } @property void
X(b v) { x = v; } }
Note that class _B is basically that of A which changes the type
a in to a b but otherwise is identical. This is to prove a point
of relationship in that _B uses b just as B should.
Class B tries to treat x as a type b as much as possible. IN
fact, by design, x is always assigned a b.
In this case, the design is safe by effort rather than type
consistency.
A f = new B();
f.x is a type of b which is of type a, so no violations here.
B g = new B();
g.x is of b type of so no violations.
but note that
f.x and g.x both accept type a. Of course g.X enforces type
safety.
Effectively the subservient types always grow with the main types
in parallel so they never get out of step. In category theory
this is equivalent to a natural transformation.
A -> a
||
vv
B -> b
Ideally one simply should express this in a meaningful way:
class B : A
{
extend b : a x;
@property b X() { x; } // note that we do not need a cast
@property void X(b v) { x = v; }
}
the syntax tells the compile that x of type a in A is of type b
in B and that b must extend a. This then gives us something more
proper to _B.
Note that now
B g = new B();
g.x = new a(); // is invalid g.x is forced to be b which is
derived from a(or anything derived from b)
These designs are very useful because they allow a type and all
it's dependencies to be extended together in a "parallel" and
keep type consistency. Natural transformations are extremely
important in specify structural integrity between related types.
While D allows this using "hacks"(well, in fact I have yet to get
the setter to properly work but it is not necessary because of
direct setting and avoiding the property setter).
This is a potential suggestion for including such a feature in
the D language to provide sightly more consistency.
Here is a "real world"(yeah, right!) example:
class food;
class catfood;
class animal { food f; }
class cat : animal { catfood : food f; }
animal -> food
||
vv
cat -> catfood
Of course, I'm not sure how to avoid the problem in D of
animal a = new cat();
a.f = new food()
auto c = cast(cat)a;
as now f in cat will be food rather than catfood.
The cast may have to be applied for the subservient types too
internally. (which the compiler can do internally) but should the
main object be set to null or just the subservient object?
auto c = cast(cat)a; // if cast(cat) is extended should c be null
or just c.f? The first case is safer but harder to fix and is the
nuke option. In this case one might require two casting methods
auto c1 = cast(cat)a; // c1 is null
auto c2 = ncast(cat)a; // c2 is not null, c2.f is null
Thoughts, ideas?
Friends in D, a new idiom?
(Please don't respond if you are going to attack me in any way! I
only accept answers that are meaningful to me and if you come up
with the wrong answer don't get offended when I tell you it's
wrong, if you do, expect to to get it thrown back in your face)
Was having to restrict write access to a type, for safety, in
general but required access by some types.
The idea is to supply the write assessors through a sub-interface:
module m;
class C
{
protected int x = 0;
@property int X() { return x; }
protected @property int X(int v) { _this.x = v; return v; }
public struct _Access
{
@property int X(int v) { _this.x = v; return v; }
C _this;
}
_Access Access;
this() { Access._this = this; }
}
import std.stdio, m;
void main()
{
C c = new C();
writeln(c.X);
c.Access.X = 4;
writeln(c.X);
getchar();
}
Here Access has the public setters and so any writing must occur
through it.
Initially I thought nested classes contained an inherent super
but I guess that is not the case?
I imagine that the pattern could be extended to really
encapsulate types better by separating write and read access. By
forcing write access through another deference, it prevents easy
write access and hence less use and makes it more explicit.
I also imagine that one could enhance this so that write access
could also be allowed by certain types.
Any ideas about this type of pattern, how to make it better,
already exists etc?
Re: On Forum Moderation
On Saturday, 26 May 2018 at 20:13:15 UTC, Walter Bright wrote: On 5/26/2018 4:12 AM, Rubn wrote: What about self moderation? If I make an unprofessional comment and want to delete it? Will this be allowed now? I guess it's more of a feature request. People have from time to time asked me to delete one of their comments, which I have done if I could. Note that forum messages that get transmitted via the mailing list cannot be unsent, nor can messages that people have already retrieved from the NNTP server be deleted from their machines, and I'm extremely reluctant to delete messages that quote yours. Think of it like getting up in front of a group of people and saying things. You can't unsay it. It's best to think before posting, and perhaps save your postings in a draft folder before transmission, in case you change your mind. In particular, be very cautious about posting when you're angry. NNTP isn't amenable to take-backsies. Just like you can't take back an email after you hit 'send'. How about the general egotistical mentalities that some of your friends here have where they talk down, are condescending, or wrongly interpret something and attack someone then when that person defends themselves the defender is the one criticized and reprimanded while the attacker is exculpated on all levels? 1. Your gang treats each other under a different set of rules than how you treat outsiders. Just because you are buddy buddy with someone doesn't mean you should make exceptions for the variation reasons that you do. Why? Because then it undermines any credibility you and your appointee's have. https://www.youtube.com/watch?v=b7t4At6S76M 2. Anyone that starts an attack is responsible for all outcomes. Cause and Effect, yet when someone defends themselves in response, even in excess, they are treated at fault. This forums methods of policing is just like how police work. If you are a fellow gang member you get special perks: https://www.youtube.com/watch?v=OflGwyWcft8 3. And if you don't REQUIRE fair and balanced treatment and hold your "cops" to a higher standard this is the kind of stuff that will happen: https://www.youtube.com/watch?v=FJaAe7sYoCA https://www.youtube.com/watch?v=X9fy4TM_HFg https://www.youtube.com/watch?v=_ohy08umEgM etc. And for those imbeciles that think I'm equating forum behavior with police murdering people, think again. I am simply pointing out that when you don't hold your enforcers to the same or higher standard, for whatever reason, then things will only progressively get worse. I could have used the same analogies as someone not taking care of their car and how it would deteriorate over time. The cop analogy is more relevant since it is similar psychological behavior. If you really care about providing professional forum then it requires the people you put in charge to act professional. This first requires them to be able to criticize themselves, none of which I have seen. It's very easy to judge other people but can they judge themselves? Expecting someone to put up with the negative behaviors of others just because that behavior hasn't crossed some arbitrary line, but is still negative, is a sure fire way to end up with a dysfunctional system. Those people who only want to spread their disease of hate are very good at going up to the line but not crossing it. Let me explain what happens: 1. Someone makes a post and asking for help, comments, etc. 2. Someone makes some type of comment where they attack in some way that person. I can point out several that have happened to me when I did not attack anyone or say anything that was negative to someone else. In one case I can point out where the person specifically said they attacked me because they said I was saying something they didn't like yet I actually did not say that at all. 3. Those people are then attacked as a defensive mechanism(A defense cannot exist without an attack and vise versa) 4. Some uppity person who wants to keep the forums clean then sides with the person he feels is in the right. If they are buddies then he will obviously side with his buddy rather than scold him and risk polluting that relationship. It is much easier to criticize and attack the person in the opposite corner. This was also done in that one specific case. The attacker and his buddies can justify any of their behavior by choosing things they do not like about the others. They never question their own behavior and therefor do realize what they say may contribute or even cause the other persons behavior. 5. The defender is then punished in some way while the real attackers are set free. This is called justice? This is called professionalism? If you are going to choose people who are biased and cannot self analyze and criticize their own behavior then you are choosing a forum that will become more dysfunctional over time with more and more
Re: C style callbacks fix for member callbacks
Investigating further, this does not seem to be pushed on the stack but set in EAX. Hence no amount of parameter placement manipulation will work. It actually becomes an easy situation although this will be invalid as it will be be whatever value is in EAX used by the caller. One cannot set this directly though but one does not have to use it. Therefor, simply using a member function here is the same as a static and no changes have to be made. Quite an easy fix. I do not know how safe it is. The docs say this is pushed and that is probably generally true.
Re: Any way to override base type with dervived in derived type
On Saturday, 26 May 2018 at 01:11:39 UTC, crimaniak wrote: On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions wrote: I'm pretty much guaranteed that in C, t will be type TT due to the design(C goes with TT like bread with butter). ... 1) Your architecture is wrong, I recommend to rethink it. Prove it genius! I recommend you rethink your absolutes without having a clue. Go back to SO, they need more Nazi's. 2) You still can deal with it using template mixins https://dlang.org/spec/template-mixin.html I've already said templates do not work. Time to rethink your answers, they are useless and you are not an authority, quick acting like one.
Re: Morale of a story: ~ is the right choice for concat operator
On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
On Friday, May 25, 2018 22:23:07 IntegratedDimensions via
Digitalmars-d wrote:
On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
> On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
>> This ambiguity bug with + has been causing well-known
>> problems since Algol. A *really* long time. Yet it gets
>> constantly welded into new languages.
>
> Yeah. I could understand that choice for a language that
> tries to be simple for beginners above everything else. But
> for large-scale application language like C#, I quess this
> just did not occur to them.
I used to program in C# quite regularly and never had this
issue. It is not a problem of the language but a problem of
the programmer.
A programmer should always know the types he is working and
the functional semantics used. While it obviously has the
potential to cause more problems it is not a huge deal in
general. I might have been caught by that "bug" once or twice
but it's usually an obvious fix. If you are moving from one
language to another or haven't programming in one much you
will have these types of problems, but they go away with
experience. To degrade the language based on that is wrong.
Languages should not be designed around noobs because then the
programmers of that language stay noobs. Think BASIC. If all
you did was programmed in basic then you would be considered a
novice programmer by today's standards. If even you were an
expert BASIC programmer, when you moved to a modern language
you would be confused. For you to say that those languages are
inferior because they don't do things like BASIC would be
wrong, it is your unfamiliarity with the language and newer
programming concepts that are the problem.
A language will never solve all your problems as a programmer,
else it would write the programs for us.
Personally, I don't think that I've ever made the mistake of
screwing up + and concatenating instead of adding or vice
versa. And at the end of the day, the programmer does need to
know the tools that they're using and use them correctly. That
being said, the language (and other tools used for programming)
can often be designed in a way that reduces mistakes - and all
programmers make mistakes. e.g. in D, implicit fallthrough in
case statements is now illegal if the case statement is
non-empty. e.g.
switch(i)
{
case 0: // legal fallthrough
case 1:
{
foo(bar());
break;
}
case 2:
{
do(something());
// illegal fallthrough
}
default: return 17;
}
Instead, the programmer must put a control flow statement there
such as break or goto. e.g.
switch(i)
{
case 0: // legal fallthrough
case 1:
{
foo(bar());
break;
}
case 2:
{
do(something());
goto case; // now explicitly goes to the next case
statement
}
default: return 17;
}
Sure, it can be argued that this should be unnecessary and that
the programmer should just get it right, but it's not an
altogether uncommon bug to screw up case statements and
invadvertently fall through to the next one when you meant to
put a break or some other control statement there. Originally,
implicit fallthrough was perfectly legal in D just like it is
in C or C++. However, when it was made illegal, it caught quite
a few bugs in existing programs - including at companies using
D. This change to the language fixed bugs and almost certainly
saved people time and money.
Designing a good programming language is a bit of an art. It's
not always easy to decide when the language should be picky
about something and when it should let the programmer shoot
themselves in the foot, but there are plenty of cases where
having the language be picky catches bugs that programmers
would otherwise make all the time, because we're not perfect.
That's part of why we have @safe in D. It disallows all kinds
of perfectly legitimate code, because it's stuff that's easy
for the programmer to screw up and often hard for them to get
right, and by having large sections of the program restricted
in what is allowed prevents all kinds of bugs. Then in the
cases where the programmer actually needs to do the unsafe
stuff, they write @system code, manually verify that it's
correct, and mark it as @trusted so that it can be called from
@safe code. Then, when they run into a memory corruption issue
later, they have a relatively small portion of the program that
they need to inspect.
A well-designed language enables the programmer to do their job
correctly and efficiently while protecting them from stupid
mistakes where reasonably possible. Using ~ instead of + costs
us almost nothing while preventing potential bugs. It's quickly
learned when you first start using D, and then the code is
clear about whether something is int
Re: Morale of a story: ~ is the right choice for concat operator
On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote: On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote: This ambiguity bug with + has been causing well-known problems since Algol. A *really* long time. Yet it gets constantly welded into new languages. Yeah. I could understand that choice for a language that tries to be simple for beginners above everything else. But for large-scale application language like C#, I quess this just did not occur to them. I used to program in C# quite regularly and never had this issue. It is not a problem of the language but a problem of the programmer. A programmer should always know the types he is working and the functional semantics used. While it obviously has the potential to cause more problems it is not a huge deal in general. I might have been caught by that "bug" once or twice but it's usually an obvious fix. If you are moving from one language to another or haven't programming in one much you will have these types of problems, but they go away with experience. To degrade the language based on that is wrong. Languages should not be designed around noobs because then the programmers of that language stay noobs. Think BASIC. If all you did was programmed in basic then you would be considered a novice programmer by today's standards. If even you were an expert BASIC programmer, when you moved to a modern language you would be confused. For you to say that those languages are inferior because they don't do things like BASIC would be wrong, it is your unfamiliarity with the language and newer programming concepts that are the problem. A language will never solve all your problems as a programmer, else it would write the programs for us.
Re: Any way to override base type with dervived in derived type
On Friday, 25 May 2018 at 10:45:23 UTC, Steven Schveighoffer
wrote:
On 5/24/18 4:24 PM, IntegratedDimensions wrote:
What I'd like to do is
class C : A
{
private override @property TT t() { return cast(TT)(_t); }
// null check if necessary
// Stuff below uses t which is now a TT
...
}
It should work, you are allowed covariant overloads. However,
private functions are not virtual, you need to make them at
least protected.
-Steve
So, I upgraded everything, tried to add the setter and get an
compile time access violation:
override @property T t(T v) { _t = v; return v; }
Changing T v to TT v gives the violation
override @property T t(TT v) { _t = v; return v; }
object.Error@(0): Access Violation
0x004850C8
0x00485C96
0x0043E22A
0x0047FB50
0x0046109A
0x0052401A
0x77D0B605 in LdrQueryProcessModuleInformation
0x77D11D02 in RtlQueryProcessLockInformation
0x77D11705 in RtlQueryProcessDebugInformation
0x77CA47DF in RtlAllocateHeap
While my specific use case is far more complex in design, the
original essentially boils down to the dpaste I gave. Probably
won't spent any time on it since I do not need the setter in this
case(can use the field directly). But a bug is probably related
to the code that fixed the "original bug" and possibly windows.
What I do know is that 2.75 did not produce this access violation
and it was the same code(I just uncommented out the setter).
The original dpaste code that did pass, I though, doesn't seem to
pass now. I thought it was working for 2.80 and so I changed it
to 2.69 and it failed but I might have made a mistake or the page
lagged.
Either way, maybe you have a clue for future reference.
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 04:28:31 UTC, Jordan Wilson wrote:
On Friday, 25 May 2018 at 03:34:43 UTC, IntegratedDimensions
wrote:
On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC,
IntegratedDimensions wrote:
the idea in the first place. I needed a hammer but no one
invented it. If I give you my use case then there would be
two main outcomes: You attempt to find a workaround for the
use case or claim that it is not applicable. These are the
"I have a rock that should work as good as that hammer
thingy you want" and "Hammers are useless".
3rd outcome: noobs like me who read the forums who benefit
from such discussion.
Of course, you could be as disinterested in the 3rd outcome
as you are the 1st and 2nd, and that's completely fair.
Jordan
Giving specific examples that are not applicable to your
knowledge base won't help you. If you are too noobish to see
how unifying foreach across non-arrays is useful then you have
no experience where it is. Sure I could give some examples but
then you have the option of excepting them as useful or saying
they are too trivial.
If you can't think of examples on your own then you are
probably not ready for the increase expressiveness of what the
feature allows. It simply means don' t use the new feature.
Why worry about something you don't understand?
void foo(T)(T t)
{
foreach(a; t)
{
}
}
Does that help? I doubt it. If you are too much of a noob you
won't get why the above makes certain things easier. If you
don't have a good working knowledge of templates then you
won't see how such a feature enhancement can simplify things.
So, I will solve the homework problem for you:
auto max(T)(T t)
{
baseTypeOf(T) a;
foreach(a; t)
a = max(a,t)
return a;
}
max(3) = 3
max([3,4,5]) = 5
See? and this is just an arbitrary example that I hope makes
you happy. My examples are more complex and I don't see why it
is necessary for me to waste 30m of my time extracting and
developing a demo just to show that the feature is useful. It
really boils down to the fact that if you can't see it being
useful to you then it isn't and if you can then it is. A noob
isn't going to be able to determine if the feature is sound or
not so it is pointless for a noob to really worry about it.
I genuinely read these forums to increase my learning, and it's
slow progress, but I believe it does help (obviously actually
programming and looking at the many resources available online
plays a big part too).
My intention wasn't to make you justify yourself; not at all.
My intention was to simply to say that there are some people
(well, maybe it is just me) who genuinely learn from more
advanced programmers simply by reading their discussions with
other advanced programmers.
I suppose I was just trying to be encouraging, but clearly it
was more annoying, so my apologies for that.
No, not necessarily. Don't be offended. Nothing person. Maybe in
a different context things would be different but I was attacked
initially and you might have been caught in the cross fire.
My point was that you can't expect others to provide ever detail
to you so you can learn. That is not the way to learn. You must
learn to by getting behind having to be spoon fed. The only
difference between a noob and a profession is the profession has
learned how to read in between the lines. Noobs want training
wheels because it makes them feel safe, but that is also what
keeps them being a noob.
Just for you! (well I did for the other guy cause he was being an
ass but I guess it worked out for you)
https://dpaste.dzfl.pl/1f5578364b6d
The point is that if you the people that know a little more have
to spell everything out for the people who don't then it slows
everyone down. It is up to the noobs to play catch up, not up to
the "pros"(not that I would call myself a pro) to slow down.
Not everything is meant for noobs either, this question wasn't
for noobs and was for people who knew what I was talking about
and knew of a good solution. One person provided it out of about
4-5. It should have been one response, his, and that is all.
Maybe a few others could talk about specifics if interested but
there should be no expectations on my part to waste any time on
irrelevant things that do not progress the original topic. I
asked a very specific question that had a very specific answer.
Not really much room for other things... but you can see how it
turns in to a whole shit storm by someone that didn't understand,
gave a solution that wasn't really good, I told them, then they
got upset and attacked me for this and that rather than just
leave it be or try to satisfy my constraints. Sure, I could have
been more clear, but it doesn't matter how clear someone is there
will always be problems so there is a balance.
Do you want proof why? I will give it too since I feel like a
giving mood:
1. I
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 04:09:55 UTC, Mike Parker wrote: On Friday, 25 May 2018 at 03:24:32 UTC, IntegratedDimensions wrote: Show me where I asked you to do any work for me. You are an imbecile. Just trying to stir up trouble because you obviously don't know how to read. You didn't like my response and so you are being a dick... simple as that. I'm sure you will get your supporters... some dicks like to other dicks. What is your point? Where the fuck did I say that anyone needed to implement this feature? I like you parse things in ways that suit your agenda. Very convenient for you. You seem to have a big problem communicating in a normal fashion. I tried to communicate on your level. Hopefully you understand me this time. This sort of aggression is not appreciated in these forums. There's nothing in his post to warrant such a response. Please tone it down. Thanks! Way to take sides. Where was no aggression in my original post and he intentionally manipulated what I said and attacked me, yet you try to reprimand me? How about you try being fair and objective? Maybe this shit wouldn't happen if people like him didn't jump the gun and people like you wouldn't back him up allowing such behavior? I can be peaceful and cordial but I expect the same. Show me where I attacked first and I will admit guilt and apologize! Show me! I dare you! If not, then STFU because you are part of the problem. If you don't like my attitude then don't have one yourself. Veiling your bias in nice tones does not admonish you of guilt. Wanting me to behave because I go overboard on someone who started it is exactly why I went overboard. Because you will allow the more subtle attacks because, what? They don't involve cuss words? Because they are outright threatening? Check your buddy and stop supporting his behavior and maybe these things won't happen? Kinda hard to do when your biased though?
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 09:57:20 UTC, meppl wrote:
On Friday, 25 May 2018 at 03:34:43 UTC, IntegratedDimensions
wrote:
On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC,
IntegratedDimensions wrote:
[...]
3rd outcome: noobs like me who read the forums who benefit
from such discussion.
Of course, you could be as disinterested in the 3rd outcome
as you are the 1st and 2nd, and that's completely fair.
Jordan
So, I will solve the homework problem for you:
auto max(T)(T t)
{
baseTypeOf(T) a;
foreach(a; t)
a = max(a,t)
return a;
}
max(3) = 3
max([3,4,5]) = 5
you didnt take your time to give a proper example. That code is
wrong in multiple ways. People would have to reconstruct your
code
Why should I take my time to give a fucking proper example? Why
the hell are you people so retarded?
https://dpaste.dzfl.pl/1f5578364b6d
Here is your "proper" example since you seem to need to be spoon
fed like a little baby. I'm sorry, but if you can't read pseudo
code you shouldn't be programming. To bitch at someone else for
crossing your t's and dotting your i's when they have no
obligation is not only moronic but selfish. I have better things
to do then babysit you to make sure you can understand things.
How bout you learn to code on your own so you can fill in the
blanks rather than needing everything spelled out? I will only
spell everything out once for you, don't expect it and don't ask
for it any more:
import std.stdio;
auto elseOnly(T)(T t) {
import std.range: isInputRange;
static if (isInputRange!T) {
return t;
} else {
import std.range: only;
return only(t);
}
}
auto max(T)(T a, T b)
{
return (a >= b) ? a : b;
}
auto max(T)(T t)
{
import std.traits;
static if (isArray!(T)) typeof(t[0]) c; else T c;
foreach(a; t.elseOnly())
c = max(a,c);
return c;
}
void main()
{
auto x = max(3);
auto y = max([3,4,5]);
writeln(x);
writeln(y);
}
If there is some specific problem with you not understanding
pseudo code then you can ask for clarification, but don't try to
pretend it is my problem for your ignorance.
Re: Any way to override base type with dervived in derived type
On Friday, 25 May 2018 at 10:45:23 UTC, Steven Schveighoffer
wrote:
On 5/24/18 4:24 PM, IntegratedDimensions wrote:
What I'd like to do is
class C : A
{
private override @property TT t() { return cast(TT)(_t); }
// null check if necessary
// Stuff below uses t which is now a TT
...
}
It should work, you are allowed covariant overloads. However,
private functions are not virtual, you need to make them at
least protected.
-Steve
Wow, I didn't expect that! Thanks, exactly what I needed.
Unfortunately property setters seem to be broken.
https://dpaste.dzfl.pl/24ce8c7e0681
Seems this is a bug though that has been fix as it only happens
on certain the older compilers. I had to downgrade because in the
latest I get a lot of link errors ;/
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 04:31:54 UTC, Neia Neutuladh wrote: On Friday, 25 May 2018 at 03:24:32 UTC, IntegratedDimensions wrote: Show me where I asked you to do any work for me. The subject of your post is in the imperative. It's a command. You are an imbecile, which I will attempt to prove: The subject describes the context of the post. It is not a command and no where says for everyone to drop what they are doing on work on it. That is what you want to read in to it. You are an evil person and want to spread your vitriol and hate by trying to read in the most negative things you can. People who just have an idea that they want to discuss but aren't actively proposing as a change tend to communicate that explicitly. They say something like "what do you think about this idea?" or "would anyone find this useful?" or "soliciting feedback". It doesn't matter. People that want to force other people to do things usually use guns. If we restrict our selves to forum posts someone will say something like: "YOU BETTER IMPLEMENT THIS OR ELSE!" or "You guys have to implement this now!" The fact is, you chose to be a douchebag because you are a douchebag. No where in my post did I have any animosity. Why? Because I didn't put in any. I had no animosity... just because you can misinterpret it and find it means that is something you projected on to it. Even if I wrote "GO FUCK YOURSELF!", If I put no animosity in it then there is none and it means nothing what I wrote why? Because that could be also said in a joking way as we know some people say it that way. The fact is, I said nothing even close to being negative and the fact is you jumped to the conclusion that it was. In fact, what you did was get pissed because I rejected your comment as being useful and then that made you negative so you decided to be a douchebag. That is your problem, not mine. You seem to have a need for everyone to accept everything you say as the absolute truth. God complex? At any rate, if you're just looking for whether anyone else thinks it would be useful, the answer seems to be no. Um, another condescending attack? First, How do you know what others thing? Second, someone found it useful enough to create a simple piece of that emulates the behavior. If they thought it was absolutely useless as you are trying to imply they would never bothered. Again, it is you projecting. You have a problem, you like to be a douchebag. You are an imbecile. Just trying to stir up trouble because you obviously don't know how to read. You didn't like my response and so you are being a dick... simple as that. I'm sure you will get your supporters... some dicks like to other dicks. I've first-hand experience with moderation on this forum: nothing public, at most a private email from Walter or Andrei. What are you saying? You have rubbed dicks with them? There are a lot of douchebag moderators, in fact, most. Similar to cops where they get a little authority and they think they are a god. So, I fail to see exactly what you are saying here. This does a terrible job of setting expectations of community behavior. It makes it look like there is no moderation at all. I have no idea whether the moderation I experienced was unique or standard -- do most people not even get a warning? If someone is rude to me, are they tolerated while I am rebuked? You know what sets terrible expectations? When someone decides to read a post, reply trying to be helpful, when they are told their help wasn't on track they get pissed off then write posts that are condescending in attitude that is totally irrelevant to the original discussion and pretends to take the high ground. If you notice I didn't attack anyone but you and that occurred after you attacked me. You, with your inflated ego expected me to roll over. 1. This is my thread, I shouldn't have to defend myself against any douchbag wants to but in and cause trouble. 2. I hope that policy changes. This is not an impossibly huge request, but it isn't trivial by any means. There are two socially acceptable ways to get people to implement something you want: convince them it's worthwhile, or pay them. Um, no, it is trivial. The relevant code is here: https://github.com/dlang/dmd/blob/aa8fc584b92e736290f359596ec9e0aae857ae2c/src/dmd/statementsem.d#L1069 If, looking at it, you still think it's trivial, then you must be considerably better at this than me. And have a much firmer idea in your head of how this feature would work than you've told us. 1. The code isn't terrible, but I have never messed with the D source so it is not a test of my skills. It is a test of someone that actually deals in the idiom that is used along with the style and methods so that they can create proper features rather than for me to hack it together. The only people that can answer if this feature would be difficult to implement are
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions
wrote:
the idea in the first place. I needed a hammer but no one
invented it. If I give you my use case then there would be two
main outcomes: You attempt to find a workaround for the use
case or claim that it is not applicable. These are the "I have
a rock that should work as good as that hammer thingy you
want" and "Hammers are useless".
3rd outcome: noobs like me who read the forums who benefit from
such discussion.
Of course, you could be as disinterested in the 3rd outcome as
you are the 1st and 2nd, and that's completely fair.
Jordan
Giving specific examples that are not applicable to your
knowledge base won't help you. If you are too noobish to see how
unifying foreach across non-arrays is useful then you have no
experience where it is. Sure I could give some examples but then
you have the option of excepting them as useful or saying they
are too trivial.
If you can't think of examples on your own then you are probably
not ready for the increase expressiveness of what the feature
allows. It simply means don' t use the new feature. Why worry
about something you don't understand?
void foo(T)(T t)
{
foreach(a; t)
{
}
}
Does that help? I doubt it. If you are too much of a noob you
won't get why the above makes certain things easier. If you don't
have a good working knowledge of templates then you won't see how
such a feature enhancement can simplify things.
So, I will solve the homework problem for you:
auto max(T)(T t)
{
baseTypeOf(T) a;
foreach(a; t)
a = max(a,t)
return a;
}
max(3) = 3
max([3,4,5]) = 5
See? and this is just an arbitrary example that I hope makes you
happy. My examples are more complex and I don't see why it is
necessary for me to waste 30m of my time extracting and
developing a demo just to show that the feature is useful. It
really boils down to the fact that if you can't see it being
useful to you then it isn't and if you can then it is. A noob
isn't going to be able to determine if the feature is sound or
not so it is pointless for a noob to really worry about it.
Re: extend foreach to work on non-arrays
On Friday, 25 May 2018 at 03:09:26 UTC, Neia Neutuladh wrote: On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions wrote: If you can't find validity in the suggestion based on it's own inherent usefulness than the only way I can convince you is to provide examples that you actually find useful... that makes it difficult on my part and is not fair to me. You are asking us all to do work for you. You're asking everyone to learn about this new language element. (And yes, we would have to learn, since it means the compiler is less able to find errors in our code, because more code is valid.) You're asking Walter Bright or another compiler developer to implement this feature for you, and write the tests, and write the documentation, and support this new code for years. Show me where I asked you to do any work for me. You are an imbecile. Just trying to stir up trouble because you obviously don't know how to read. You didn't like my response and so you are being a dick... simple as that. I'm sure you will get your supporters... some dicks like to other dicks. This is not an impossibly huge request, but it isn't trivial by any means. There are two socially acceptable ways to get people to implement something you want: convince them it's worthwhile, or pay them. Um, no, it is trivial. You just want to be an ass. It was already proved trivial by aliak. You just have some chip on your shoulder and are trying to make a general point when this is a specific problem. Compare: there's no socket.io client or server library for D. You should implement one. Does my saying so make you inclined in any way to write a socket.io library? What is your point? Where the fuck did I say that anyone needed to implement this feature? I like you parse things in ways that suit your agenda. Very convenient for you. You seem to have a big problem communicating in a normal fashion. I tried to communicate on your level. Hopefully you understand me this time.
Re: Any way to override base type with dervived in derived type
On Friday, 25 May 2018 at 01:42:48 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 01:17:45 UTC, IntegratedDimensions
wrote:
On Friday, 25 May 2018 at 01:02:00 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 00:15:39 UTC, IntegratedDimensions
wrote:
On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC,
IntegratedDimensions wrote:
class T;
class TT : T;
interface I
{
@property T t();
}
abstract class A
{
T _t;
@property T t() { return _t; }
}
class C : A
{
// Stuff below uses t as TT but compiler, of course,
treats t as T
...
}
The issue is that I programmed the class C with a variable
that directly was based off TT, I later subderived T from
TT and exposed it in I. (TT was refactored in to T and not
T)
As as a side note:
I can hardly follow this, as you don't show, where you use
the interface I. However, especially if TT was refactored
in such a way, that is a set difference of T and not T, why
you choose to derive from T instead of to contain T?
It really should be obvious that A was meant to derive from
I. This is just standard oop. Simply leaving off : I should
not be a deal breaker because it would not change the whole
problem from black to white or vice versa.
T is a member to be included. You can only derive from one
class. C can't derive from both A and T and even if it did,
it would mean something else.
https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance
Well, can imagine useful cases though...
This is not a composition pattern.
This is a parallel inherentence pattern.
TT : T = T
|| |
vv v
C : A : I
TT is used with C and T with I.
When C changes to C', TT : T changes to TT' : T
All functions that use TT in C are forced to use it as if it
were of type T rather than TT which requires a bunch of
casts.
This is generally a violation of type logic. There is
nothing in that prevents t from being something like TTT
which has no direct relation to TT.
But the programming logic of the code enforces t to be of
type TT in C *always*. So I don't know why I would have to
use casting all the time. It would be nice if there where a
simple logical way to enforce a design pattern in the type
system knowing that it is enforced at runtime. This makes
cleaner code, nothing else.
But all the code in C assumes t is of type TT but now due
to the interface it looks like a T, even though internally
it is actually a TT.
What I'd like to do is
class C : A
{
private override @property TT t() { return
cast(TT)(_t); } // null check if necessary
// Stuff below uses t which is now a TT
...
}
or whatever.
This is simply so I don't have to rename or cast all my
uses of t in C to type TT.
I'm pretty much guaranteed that in C, t will be type TT
due to the design(C goes with TT like bread with butter).
So, it would be nice if somehow I could inform the type
system that in C, t is always of type TT and so treat it
as such rather than forcing me to explicitly cast for
every use. Again, I could rename things to avoid the same
name usage but in this case it is not necessary because of
the design.
Is there any semantics that can get me around having to
rename?
Maybe, you are looking for Curiously Recurring Template
Pattern?
´´´
interface I(P)
{
@property P t();
}
abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}
class TT : T!TT
{
}
void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´
No, I am trying to keep parallel derived types consistently
connected. If A is derived from B and C from D and B uses D
then A uses C. Consistency cannot be guaranteed by the type
system at compile time because A is typed to use C, I want
to restrict it further to D.
You must put a template parameter in the interface and
specialize the class that implements the interface.
```
module runnable;
class T{}
class TT : T{}
interface I(N)
{
@property N t();
}
abstract class A(N) : I!N
{
N _t;
@property N t() { return _t; }
}
class C1 : A!T{}
class C2 : A!TT{}
void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
module runnable;
class T{}
class TT : T{}
interface I(N)
{
@property N t();
}
abstract class A(N) : I!N
{
N _t;
@property N t() { return _t; }
}
class C1 : A!T{}
class C2 : A!TT{}
void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
```
but obviously this won't work if you want to derive C1 or
C2...
or if there 100 fields.
This isn't a proper solution.
The whole issue is not outside of C but inside
Hypothetically
class C : A
{
@property TT : T t() { return _t; }
// t can be used directly as TT rather than
Re: Any way to override base type with dervived in derived type
On Friday, 25 May 2018 at 01:02:00 UTC, Basile B. wrote:
On Friday, 25 May 2018 at 00:15:39 UTC, IntegratedDimensions
wrote:
On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC,
IntegratedDimensions wrote:
class T;
class TT : T;
interface I
{
@property T t();
}
abstract class A
{
T _t;
@property T t() { return _t; }
}
class C : A
{
// Stuff below uses t as TT but compiler, of course,
treats t as T
...
}
The issue is that I programmed the class C with a variable
that directly was based off TT, I later subderived T from TT
and exposed it in I. (TT was refactored in to T and not T)
As as a side note:
I can hardly follow this, as you don't show, where you use
the interface I. However, especially if TT was refactored in
such a way, that is a set difference of T and not T, why you
choose to derive from T instead of to contain T?
It really should be obvious that A was meant to derive from I.
This is just standard oop. Simply leaving off : I should not
be a deal breaker because it would not change the whole
problem from black to white or vice versa.
T is a member to be included. You can only derive from one
class. C can't derive from both A and T and even if it did, it
would mean something else.
https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance
Well, can imagine useful cases though...
This is not a composition pattern.
This is a parallel inherentence pattern.
TT : T = T
|| |
vv v
C : A : I
TT is used with C and T with I.
When C changes to C', TT : T changes to TT' : T
All functions that use TT in C are forced to use it as if it
were of type T rather than TT which requires a bunch of casts.
This is generally a violation of type logic. There is nothing
in that prevents t from being something like TTT which has no
direct relation to TT.
But the programming logic of the code enforces t to be of type
TT in C *always*. So I don't know why I would have to use
casting all the time. It would be nice if there where a simple
logical way to enforce a design pattern in the type system
knowing that it is enforced at runtime. This makes cleaner
code, nothing else.
But all the code in C assumes t is of type TT but now due to
the interface it looks like a T, even though internally it
is actually a TT.
What I'd like to do is
class C : A
{
private override @property TT t() { return cast(TT)(_t);
} // null check if necessary
// Stuff below uses t which is now a TT
...
}
or whatever.
This is simply so I don't have to rename or cast all my uses
of t in C to type TT.
I'm pretty much guaranteed that in C, t will be type TT due
to the design(C goes with TT like bread with butter).
So, it would be nice if somehow I could inform the type
system that in C, t is always of type TT and so treat it as
such rather than forcing me to explicitly cast for every
use. Again, I could rename things to avoid the same name
usage but in this case it is not necessary because of the
design.
Is there any semantics that can get me around having to
rename?
Maybe, you are looking for Curiously Recurring Template
Pattern?
´´´
interface I(P)
{
@property P t();
}
abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}
class TT : T!TT
{
}
void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´
No, I am trying to keep parallel derived types consistently
connected. If A is derived from B and C from D and B uses D
then A uses C. Consistency cannot be guaranteed by the type
system at compile time because A is typed to use C, I want to
restrict it further to D.
You must put a template parameter in the interface and
specialize the class that implements the interface.
```
module runnable;
class T{}
class TT : T{}
interface I(N)
{
@property N t();
}
abstract class A(N) : I!N
{
N _t;
@property N t() { return _t; }
}
class C1 : A!T{}
class C2 : A!TT{}
void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
module runnable;
class T{}
class TT : T{}
interface I(N)
{
@property N t();
}
abstract class A(N) : I!N
{
N _t;
@property N t() { return _t; }
}
class C1 : A!T{}
class C2 : A!TT{}
void main(string[] args)
{
import std.traits;
static assert(is(ReturnType!(C1.t) == T));
static assert(is(ReturnType!(C2.t) == TT));
}
```
but obviously this won't work if you want to derive C1 or C2...
or if there 100 fields.
This isn't a proper solution.
The whole issue is not outside of C but inside
Hypothetically
class C : A
{
@property TT : T t() { return _t; }
// t can be used directly as TT rather than having to do
(cast(TT)t) everywhere t is used.
}
would solve the problem and it would scale.
The way it would work is that inside
Re: Any way to override base type with dervived in derived type
On Thursday, 24 May 2018 at 23:31:50 UTC, Alex wrote:
On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions
wrote:
class T;
class TT : T;
interface I
{
@property T t();
}
abstract class A
{
T _t;
@property T t() { return _t; }
}
class C : A
{
// Stuff below uses t as TT but compiler, of course, treats
t as T
...
}
The issue is that I programmed the class C with a variable
that directly was based off TT, I later subderived T from TT
and exposed it in I. (TT was refactored in to T and not T)
As as a side note:
I can hardly follow this, as you don't show, where you use the
interface I. However, especially if TT was refactored in such a
way, that is a set difference of T and not T, why you choose to
derive from T instead of to contain T?
It really should be obvious that A was meant to derive from I.
This is just standard oop. Simply leaving off : I should not be
a deal breaker because it would not change the whole problem from
black to white or vice versa.
T is a member to be included. You can only derive from one class.
C can't derive from both A and T and even if it did, it would
mean something else.
https://en.wikipedia.org/wiki/Composition_over_inheritance
http://wiki.c2.com/?CompositionInsteadOfInheritance
Well, can imagine useful cases though...
This is not a composition pattern.
This is a parallel inherentence pattern.
TT : T = T
|| |
vv v
C : A : I
TT is used with C and T with I.
When C changes to C', TT : T changes to TT' : T
All functions that use TT in C are forced to use it as if it were
of type T rather than TT which requires a bunch of casts.
This is generally a violation of type logic. There is nothing in
that prevents t from being something like TTT which has no direct
relation to TT.
But the programming logic of the code enforces t to be of type TT
in C *always*. So I don't know why I would have to use casting
all the time. It would be nice if there where a simple logical
way to enforce a design pattern in the type system knowing that
it is enforced at runtime. This makes cleaner code, nothing else.
But all the code in C assumes t is of type TT but now due to
the interface it looks like a T, even though internally it is
actually a TT.
What I'd like to do is
class C : A
{
private override @property TT t() { return cast(TT)(_t); }
// null check if necessary
// Stuff below uses t which is now a TT
...
}
or whatever.
This is simply so I don't have to rename or cast all my uses
of t in C to type TT.
I'm pretty much guaranteed that in C, t will be type TT due to
the design(C goes with TT like bread with butter).
So, it would be nice if somehow I could inform the type system
that in C, t is always of type TT and so treat it as such
rather than forcing me to explicitly cast for every use.
Again, I could rename things to avoid the same name usage but
in this case it is not necessary because of the design.
Is there any semantics that can get me around having to rename?
Maybe, you are looking for Curiously Recurring Template Pattern?
´´´
interface I(P)
{
@property P t();
}
abstract class T(P) : I!P
{
P _p;
@property P t() { return _p; }
}
class TT : T!TT
{
}
void main()
{
auto tt = new TT();
static assert(is(typeof(tt.t) == TT));
}
´´´
No, I am trying to keep parallel derived types consistently
connected. If A is derived from B and C from D and B uses D then
A uses C. Consistency cannot be guaranteed by the type system at
compile time because A is typed to use C, I want to restrict it
further to D.
Re: extend foreach to work on non-arrays
On Thursday, 24 May 2018 at 23:08:39 UTC, aliak wrote:
On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions
wrote:
Doesn't make any sense?
foreach(a; x)
if x is not an array then a = x and the loop reduces simply
and function to the case it is not so their can be no harm.
It unifies the concepts so that one does not have to worry if
x is an array or not and can offer no harm since when x is
not an array everything simply reduces to an an alias of x.
You can already do this for any type you define:
class Foo
{
auto iterate() { return only(this); }
alias iterate this;
}
Can you give examples of code that is awkward today that would
be simplified with your proposal? I don't expect people to
give full cost-benefit analyses for every suggestion, but it'd
be nice if you could at least mention some of the upsides.
And then you can generalize this for any type
auto elseOnly(T)(T t) {
import std.range: isInputRange;
static if (isInputRange!T) {
return t;
} else {
import std.range: only;
return only(t);
}
}
foreach(i; 3.elseOnly) {
}
foreach(i; [1, 2, 3].elseOnly) {
}
Cheers
- Ali
cool, and this is optimal, right? non-arrays are not converted in
to arrays, etc?
Re: extend foreach to work on non-arrays
On Thursday, 24 May 2018 at 23:03:34 UTC, meppl wrote:
On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions
wrote:
Doesn't make any sense?
foreach(a; x)
if x is not an array then a = x and the loop reduces simply
and function to the case it is not so their can be no harm.
It unifies the concepts so that one does not have to worry if
x is an array or not and can offer no harm since when x is not
an array everything simply reduces to an an alias of x.
on the otherhand some programmer might want to get informed buy
an error-msg, if he accidentally used a non-iteratable variable
for `foreach`-iteration. To avoid a silent bug
In this case it cannot be a bug. The foreach is simply
ignored/reduced. It would be impossible for any bug to creep
in(assuming no compiler bugs) in such cases.
foreach(a; x)
{
x[]
}
would be some type of potential bug... but that bug would also
exist without the loop. If x is not an array then the the foreach
effectively is removed and a is just auto a = x;
Any code that uses x would fail just as much as using a and no
more except.
Re: extend foreach to work on non-arrays
On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions
wrote:
Doesn't make any sense?
foreach(a; x)
if x is not an array then a = x and the loop reduces simply
and function to the case it is not so their can be no harm.
It unifies the concepts so that one does not have to worry if
x is an array or not and can offer no harm since when x is not
an array everything simply reduces to an an alias of x.
You can already do this for any type you define:
class Foo
{
auto iterate() { return only(this); }
alias iterate this;
}
Can you give examples of code that is awkward today that would
be simplified with your proposal? I don't expect people to give
full cost-benefit analyses for every suggestion, but it'd be
nice if you could at least mention some of the upsides.
The upside is that it is a composite pattern and does not require
any extra code to use preexisting functionality. There is no
downside, which is an upside.
foreach(a; x)
{
// uses a
}
gets directly converted to
{
// uses x
}
by a simple renaming/aliasing of a to x and so it cannot require
any more issues than what already exists.
Your method requires one to have access to all type definitions,
which is not the case.
I do not know why I would be required to specify a use case to
justify the usability. Most things are not usable until they are
invented. Most people did not know how useful the hammer would be
until someone created it. You have to build it for them to come.
I have my use cases which is why I came up with the idea in the
first place. I needed a hammer but no one invented it. If I give
you my use case then there would be two main outcomes: You
attempt to find a workaround for the use case or claim that it is
not applicable. These are the "I have a rock that should work as
good as that hammer thingy you want" and "Hammers are useless".
If you can't find validity in the suggestion based on it's own
inherent usefulness than the only way I can convince you is to
provide examples that you actually find useful... that makes it
difficult on my part and is not fair to me.
extend foreach to work on non-arrays
Doesn't make any sense? foreach(a; x) if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm. It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.
Any way to override base type with dervived in derived type
class T;
class TT : T;
interface I
{
@property T t();
}
abstract class A
{
T _t;
@property T t() { return _t; }
}
class C : A
{
// Stuff below uses t as TT but compiler, of course, treats t
as T
...
}
The issue is that I programmed the class C with a variable that
directly was based off TT, I later subderived T from TT and
exposed it in I. (TT was refactored in to T and not T)
But all the code in C assumes t is of type TT but now due to the
interface it looks like a T, even though internally it is
actually a TT.
What I'd like to do is
class C : A
{
private override @property TT t() { return cast(TT)(_t); } //
null check if necessary
// Stuff below uses t which is now a TT
...
}
or whatever.
This is simply so I don't have to rename or cast all my uses of t
in C to type TT.
I'm pretty much guaranteed that in C, t will be type TT due to
the design(C goes with TT like bread with butter).
So, it would be nice if somehow I could inform the type system
that in C, t is always of type TT and so treat it as such rather
than forcing me to explicitly cast for every use. Again, I could
rename things to avoid the same name usage but in this case it is
not necessary because of the design.
Is there any semantics that can get me around having to rename?
run.dlang.io/ add scrolling window and possibly src line mapping
Large code is produced for assmly and others and it would be nice if it had it's own window to scroll rather than scrolling the entire window. Also it would be nice if clicking on a line in the src scrolled to the proper location in the output It would also be nice if the imports were removed or hiddable from the source. Probably would be easier to read if also the source code lines that generate the assembly were inserted in the code where they are disassembled.
Re: Efficient idiom for fastest code
On Wednesday, 23 May 2018 at 10:55:02 UTC, Malte wrote: On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions wrote: [...] I would just do [...] [...] Thanks, I didn't think about using a for loop like that. While it is not the most general it does solve the specific case for a simple step/toggled decision.
Re: Efficient idiom for fastest code
On Wednesday, 23 May 2018 at 03:00:17 UTC, Nicholas Wilson wrote:
On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions
wrote:
Many times in expensive loops one must make decisions.
Decisions must be determined and the determination costs.
for(int i = 0; i < N; i++)
{
if(decision(i)) A; else B;
}
the if statement costs N times the cycle cost.
In some cases the decision holds for continuous ranges. For
some 0 <= n <= N the decision is constant, but n is
arbitrary(determined by unknown factors at compile time).
One can speed up the routine by using something akin to a
simplified strategy pattern where one uses
functions/delegates/lambdas to code a faster version without
the test:
for(int i = 0; i < N; i++)
{
d = (){ if(decision(i)) A; else d = () { B; };
d();
}
assuming you meant
auto d = (int i){ if(decision(i)) A; else d = (int i) { B; };};
for(int i = 0; i < N; i++)
{
d(i);
}
this code basically reduces to
for(int i = 0; i < N; i++)
{
B;
}
Once the decision fails, which we assume once it fails it
always fails in this particular case.
Therefor, once the decision fails it kicks in the "faster"
code. Suppose decision is very slow.
The cycle cost is then n times rather than N times.
In general, such techniques can be used to speed up code,
sometimes significantly, but are difficult to implement using
a standard pattern and for more complex decision functions.
Does anyone see any way to use some some of D's power to help
simplify such things but not using something like a strategy
pattern or complexifying the overall design(using advanced
techniques such as templates, mixins is not making the code
more complex).
If decision is pure, consider using static foreach
(iota(N).map!decision) { ... }to unroll it at compile time.
even if it isn't the compiler may still be able to factor out
parts of repeated calls to decision, look at the assembly/IR to
confirm this.
Otherwise PROFILE! (and use profile guided optimisation!
this implies using a compiler other than DMD which if you care
about performance you should be doing anyway)
Blindly trying to optimise is just as likely to hurt
performance.
in particular don't underestimate the branch predictor. Even if
decision is complex, if there is a pattern in evaluating
iota(n).map!decision the branch predictor will pick up on it.
In terms of exploiting knowledge of decision a priori that the
compiler somehow lacks you really don't have much option but to
do it yourself.
I knew someone was going to say that and I forgot to say DON'T!
Saying to profile when I clearly said these ARE cases where they
are slow is just moronic. Please don't use default answers to
arguments.
This was a general question about cases on how to attack a
problem WHEN profiling says I need to optimize. Your SO 101
answer sucks! Sorry!
To prove to you that your answer is invalid:
I profile my code, it says that it is very slow and shows that it
is do to the decision checking... I then I have to come here and
write up a post trying to explain how to solve the problem. I
then get a post telling me I should profile. I then respond I did
profile and that this is my problem. A lot of wasted energy when
it is better to know a general attack strategy. Yes, some of us
can judge if code is needed to be optimized before profiling. It
is not difficult. Giving a generic answer that always does not
apply and is obvious to anyone trying to do optimization is not
helpful. Everyone today pretty must does not even optimize code
anymore... this isn't 1979. It's not ok to keep repeating the
same mantra. I guess we should turn this in to a meme?
The reason I'm getting on to you is that the "profile before
optimization" sounds a bit grade school, specially since I wasn't
talking anything about profiling but a general programming
pattern speed up code, which is always valid but not always
useful(and hence that is when profiling comes in).
Efficient idiom for fastest code
Many times in expensive loops one must make decisions. Decisions
must be determined and the determination costs.
for(int i = 0; i < N; i++)
{
if(decision(i)) A; else B;
}
the if statement costs N times the cycle cost.
In some cases the decision holds for continuous ranges. For some
0 <= n <= N the decision is constant, but n is
arbitrary(determined by unknown factors at compile time).
One can speed up the routine by using something akin to a
simplified strategy pattern where one uses
functions/delegates/lambdas to code a faster version without the
test:
for(int i = 0; i < N; i++)
{
d = (){ if(decision(i)) A; else d = () { B; };
d();
}
this code basically reduces to
for(int i = 0; i < N; i++)
{
B;
}
Once the decision fails, which we assume once it fails it always
fails in this particular case.
Therefor, once the decision fails it kicks in the "faster" code.
Suppose decision is very slow.
The cycle cost is then n times rather than N times.
In general, such techniques can be used to speed up code,
sometimes significantly, but are difficult to implement using a
standard pattern and for more complex decision functions.
Does anyone see any way to use some some of D's power to help
simplify such things but not using something like a strategy
pattern or complexifying the overall design(using advanced
techniques such as templates, mixins is not making the code more
complex).
Re: Locking data
On Tuesday, 22 May 2018 at 23:09:24 UTC, Sjoerd Nijboer wrote:
On Tuesday, 22 May 2018 at 22:17:05 UTC, IntegratedDimensions
wrote:
On Tuesday, 22 May 2018 at 22:10:52 UTC, Alex wrote:
On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions
wrote:
an idea to lock data by removing the reference:
class A
{
Lockable!Data data;
}
The idea is that when the data is going to be used, the user
locks the data. The trick here is that data is a pointer to
the data and the pointer is set to null when locked so no
other data can use it(they see a null reference). To unlock,
the data is reassigned:
auto d = data.lock(); // A.data is now null deals with sync
issues
//use d
d = data.unlock(d); // restores A.data (A.data = d;) and
sets d to null so any future reference is an error(could
produce bugs but should mostly be access violations)
Anyone else trying to use data will see that it is null
while it is locked.
This basically pushes the standard locking mechanisms in to
the Lockable!data(first come first serve) and code that has
not captured the data see's it simply as null.
Anyone use know if there exists an idiom like this and what
it is called? Maybe some idiomatic code that is efficient?
Ideally I'd want to be able to treat the Lockable!Data as
Data. Right now I have to classes(or pointers to structs)
and few weird hacks. I think what I'll have to end up doing
is having a Locked!Data structure that is returned instead
or use an UFCS. The idea being to attach the lock and unlock
methods.
Are you aware of NullableRef?
https://dlang.org/library/std/typecons/nullable_ref.html
Yes.
Does it fit somehow?
Not really. It could be used to wrap the data when used as a
struct but it offers none of the locking features which is the
ultimate goal.
The idea is simply that one can lock the data to get exclusive
access. Normally standard locking tricks are used but in this
case the idea is to do all that behind the scenes. Locking the
data makes all other accessors see null data(and crash or
properly test). This is a first come first serve or single
access type of pattern but sort of removes the data from
prying eyes while it is being used.
how about something like
import core.atomic;
class Lockable!Data
{
private __gshared Lockable!Data data;
}
struct Locked!Lockable!Data
{
private TailShared!Lockable!Data lockedData;
private Lockable!Data lockableData;
this(Lockable!Data lockableData)
{
this.lockableData = lockableData;
while( (lockedData= atomicLoad(lockableData)) !is null)
if(cas(lockedData, lockedData, null))
break;
}
~this()
{
atomicStore(lockedData, lockableData );
}
alias lockedData.data this;
}
With something like this you should be able to do RAII like
semantics on your data.
You share a Lockable!Data which you want use, and then you can
access it if you instantiate a Locked!Lockable!Data struct with
it.
FYI, my atomics isn't all that great so don't expect this to
work.
This is similar to what I am doing... maybe "identical".
Re: Locking data
On Tuesday, 22 May 2018 at 22:10:52 UTC, Alex wrote:
On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions
wrote:
an idea to lock data by removing the reference:
class A
{
Lockable!Data data;
}
The idea is that when the data is going to be used, the user
locks the data. The trick here is that data is a pointer to
the data and the pointer is set to null when locked so no
other data can use it(they see a null reference). To unlock,
the data is reassigned:
auto d = data.lock(); // A.data is now null deals with sync
issues
//use d
d = data.unlock(d); // restores A.data (A.data = d;) and sets
d to null so any future reference is an error(could produce
bugs but should mostly be access violations)
Anyone else trying to use data will see that it is null while
it is locked.
This basically pushes the standard locking mechanisms in to
the Lockable!data(first come first serve) and code that has
not captured the data see's it simply as null.
Anyone use know if there exists an idiom like this and what it
is called? Maybe some idiomatic code that is efficient?
Ideally I'd want to be able to treat the Lockable!Data as
Data. Right now I have to classes(or pointers to structs) and
few weird hacks. I think what I'll have to end up doing is
having a Locked!Data structure that is returned instead or use
an UFCS. The idea being to attach the lock and unlock methods.
Are you aware of NullableRef?
https://dlang.org/library/std/typecons/nullable_ref.html
Yes.
Does it fit somehow?
Not really. It could be used to wrap the data when used as a
struct but it offers none of the locking features which is the
ultimate goal.
The idea is simply that one can lock the data to get exclusive
access. Normally standard locking tricks are used but in this
case the idea is to do all that behind the scenes. Locking the
data makes all other accessors see null data(and crash or
properly test). This is a first come first serve or single access
type of pattern but sort of removes the data from prying eyes
while it is being used.
Locking data
an idea to lock data by removing the reference:
class A
{
Lockable!Data data;
}
The idea is that when the data is going to be used, the user
locks the data. The trick here is that data is a pointer to the
data and the pointer is set to null when locked so no other data
can use it(they see a null reference). To unlock, the data is
reassigned:
auto d = data.lock(); // A.data is now null deals with sync issues
//use d
d = data.unlock(d); // restores A.data (A.data = d;) and sets d
to null so any future reference is an error(could produce bugs
but should mostly be access violations)
Anyone else trying to use data will see that it is null while it
is locked.
This basically pushes the standard locking mechanisms in to the
Lockable!data(first come first serve) and code that has not
captured the data see's it simply as null.
Anyone use know if there exists an idiom like this and what it is
called? Maybe some idiomatic code that is efficient?
Ideally I'd want to be able to treat the Lockable!Data as Data.
Right now I have to classes(or pointers to structs) and few weird
hacks. I think what I'll have to end up doing is having a
Locked!Data structure that is returned instead or use an UFCS.
The idea being to attach the lock and unlock methods.
Re: C style callbacks fix for member callbacks
On Monday, 21 May 2018 at 02:23:27 UTC, ag0aep6g wrote: I tried this. Your code crashes in windows dmd x86 x64. Hm. Works for me in a virtual machine. But I'm not surprised that it's fragile. It might be completely wrong, and it just happens to look alright on my machine. https://run.dlang.io/is/CMNnJY Shows the static version produces the same code as the non-static. The code was probably compiled on linux. I can't tell though on my machine what is going on since I cannot disassemble properly and what I do see is far more complex.
Re: http://asm.dlang.org/ needs updating
On Monday, 21 May 2018 at 20:29:13 UTC, Steven Schveighoffer wrote: On 5/20/18 12:47 PM, IntegratedDimensions wrote: load and save are not working, an example is always compiled in. No code in the input box still shows examples code in the disassembly. Why do we even have asm.dlang.org any more? The latest version on there is 2.071. I'd recommend using run.dlang.io, and clicking the ASM button. Or use d.godbolt.org -Steve It would be nice if run.dlang.io didn't include phobos in the asm display. Using selective imports doesn't help. Creates a huge assembly just to use writeln.
Re: http://asm.dlang.org/ needs updating
On Monday, 21 May 2018 at 20:29:13 UTC, Steven Schveighoffer wrote: On 5/20/18 12:47 PM, IntegratedDimensions wrote: load and save are not working, an example is always compiled in. No code in the input box still shows examples code in the disassembly. Why do we even have asm.dlang.org any more? The latest version on there is 2.071. I'd recommend using run.dlang.io, and clicking the ASM button. Or use d.godbolt.org -Steve the run.dlang.io seems to work and is better than the others. asm.dlang.org is a clone of d.godbolt.org and both have the same problems. Neither give the proper assembly nor a verbose assembly while run.dlang.io seems to give it all. Thanks.
Re: Real Int24
On Monday, 21 May 2018 at 15:41:21 UTC, Simen Kjærås wrote:
On Saturday, 19 May 2018 at 18:44:42 UTC, IntegratedDimensions
wrote:
On Saturday, 19 May 2018 at 18:19:35 UTC, IntegratedDimensions
wrote:
Is there any way to create an int24 type that behaves just
like any other built in type without having to reimplement
everything?
In fact, what I'd like to do is create an arbitrary type:
struct atype(T)
{
}
where atype(T) is just a "view" in to N_T bits interpreted as
T, an enum.
If T is bit, then the N = 1 and the interpretation is 1 bit.
If T is byte, then the N = 8 and the interpretation is 7 bits
followed by 1 signed bit.
If T is int24, then the N = 24 and the interpretation is 23
bits followed by 1 signed bit.
The idea is the storage of atype is exactly N bits. If this is
not possible due to boundary issues then N can always be a
multiple of 8(which is for my use cause is the smallest).
D does not support types that take up less than one byte of
space. It's possible to make types that represent less than one
byte - bool may be considered such an example - but they still
take up at least 1 byte.
If you create a custom range type, you could pack more than one
element in each byte, see std.bitmanip.BitArray[0] for an
example.
The main thing is that I would like to be able to use atype as
if it were a built in type.
If N = 24, 3 bytes, I want to be able to create arrays of
atype!int24[] which work just as if they were arrays of bytes
without any exception or special cases.
atype!byte would be equivalent to byte and reduce to the
compiler internals. I'm not looking to create a "view" of an
array. I want a standalone type that can behave as all the
desired types needed, which is most of the numerical types of
D and some of the ones it neglected like 24-bit ints, 48-bit
ints, etc. Ideally, any type could be used and the "most
optimal" code is generated while being able to use the types
using the standard model.
We already have std.numeric.CustomFloat[1]. As the name
implies, it only works for floats.
I hacked together something somewhat equivalent for ints:
https://gist.github.com/Biotronic/f6668d8ac95b70302015fee93ae9c8c1
Usage:
// Two's-complement, native-endian, 24-bit int type:
CustomInt!24 a;
// Unsigned, native-endian, 15-bit:
CustomInt!(15, Representation.Unsigned) b;
// Offset (-2..5) 3-bit int:
CustomInt!(3, Representation.OffsetBinary, 2) c;
// You get the idea:
CustomInt!(64, Representation.SignedMagnitude, 0,
Endianness.BigEndian) d;
Not sure this is what you're looking for, but it's at the very
least inspired by your post. :)
If what you want is a type that can represent something a
packed array of 13-bit ints, the above is not what you're
looking for - you're going to need a custom range type.
--
Simen
[0]: https://dlang.org/phobos/std_bitmanip#BitArray
[1]: https://dlang.org/phobos/std_numeric.html#.CustomFloat
Cool. I'll try it as a drop in replacement and if it works then
it works! ;) Thanks.
Just to be clear and to make sure this works the way it seems:
All types multiple of a byte are reduced to either internal
representation(byte, ubyte, short, ushort, int, uint, long,
ulong) directly(becomes an alias) or the most efficient structure
for the representation: unsigned 24-bit = 3 bytes and is
effectively ubyte[3], usigned 128-bit is ubyte[16], etc?
Non multiples are extended up one byte, so 7-bits is representing
using an byte, etc.
This seems to be the case from the code.
Now, what I didn't see was anything to work with non byte aligned
arrays of CustomInt. Would it be possible to add? I know you say
that we should use bitmanip but code could be extended to support
it relatively easily by treating an array of bits as an array of
CustomInts and the indexer can compute the appropriate offset
using the bit size.
Maybe that will require CustomIntsArray?
The idea is, say one has 7-bit ASCII represented in a ubyte[]
then they can map that to a CustomInt!7[] which will be use
CustomInt!7(but 7 bits, not 8) as representation. But, of course
CustomInt!7[3] would be 8 bits. But basically it retrieves the
correct value and stores it by doing the standard masking.
BTW, it looks like you could extend your type to deal with floats
and doubles which would make this type very robust in dealing
with arbitrary primitive types.
The idea is that any matching language types are aliased to and
those that don't are handled appropriately.
Re: C style callbacks fix for member callbacks
On Sunday, 20 May 2018 at 23:05:47 UTC, ag0aep6g wrote:
On 05/20/2018 06:48 PM, IntegratedDimensions wrote:
alias callback = extern(C) int function(const(void) a, void
*b, uint c, void* context);
(I'm assuming that `a` is supposed to be a `const(void)*`.)
Where context acts as this.
I would like to assign a D method to this callback.
class
{
callback c;
/*extern(C) static*/ int foo(const(void) a, void *b, uint
c, void* context);
this() { c = cast(callback) }
}
Unless I'm misunderstanding it, the spec seems to say that the
`this` pointer is passed as if it was an additional parameter
past the last one [1].
But that doesn't seem to be true in the implementation. At
least on Linux x86-64, `this` seems to be a hidden first
parameter. So when a method is called as a `callback`, `a`
becomes `this`, `b` becomes the first explicit parameter, `c`
the second, and `context` the third. So this works:
import std.stdio;
alias Callback = extern(C) int function(const(void)* a, void*
b, uint c,
void* context);
class C
{
int field = 43;
extern(C) int foo(void* b, uint c, C this_)
{
const(void)* a = cast(void*) this;
writeln(a, " ", b, " ", c, " ", this_.field);
return 0;
}
}
void main()
{
void* a = new int;
void* b = new int;
uint c = 42;
auto obj = new C;
Callback cb = cast(Callback) ().funcptr;
cb(a, b, c, cast(void*) obj);
writeln(a, " ", b, " ", c, " ", obj.field);
/* For comparison. Should print the same. */
}
This is all very hacky, of course. And I don't really know what
I'm doing there. So obviously, I don't recommend doing this.
But other than hacking it like that, I don't think you can pass
a method as a `callback` directly.
[1] https://dlang.org/spec/abi.html#parameters
I tried this. Your code crashes in windows dmd x86 x64.
It really shouldn't be hacky. The only difference is the "this"
is implicit normally when in this case it is explicit and
possibly in a different location than one expects.
Re: Convert mixin to function call
It should be obvious that these are simplifications. I can't pass the variables directly as parameters as in the real case the names may only be partially specified.
Re: Convert mixin to function call
https://dpaste.dzfl.pl/fb49bf834cff
import std.stdio;
auto Q(string A)()
{
auto foo()
{
auto d = mixin(Z!(A)());
return d;
}
return foo()();
}
auto X(string A, string N)()
{
return N~" = (() { int y = 4; return "~A~" + y + 5; })();";
}
auto Z(string A)()
{
return "() { int y = 4; return "~A~" + y + 5; }";
}
void main()
{
int x = 3;
double y = 0;
pragma(msg, (X!("x", "y")()));
mixin(X!("x", "y")());
y = Q!("x")();
writeln(y);
}
using Q is more ideomatic but foo does not have access to x which
is required(since Q should behave like a string mixin as far as
scope is concerned).
Re: Convert mixin to function call
Also, one thing that would help would be able to create identifier names that are unique to avoid collisions. Does D have any ability to do such a thing?
Convert mixin to function call
I have a string mixin that returns a value or function that uses
the mixed in scope.
Currently I have to wrap the mixin in a delegate or local
function as to be able to get the value:
int x = 3;
int y = 1;
auto foo() { mixin(X!("x")); }
This allows the the mixin to see the scope but keep the mixin
variables local so they do not shadow anything unintentionally.
auto X(string A)()
{
return "int y = 4; return "~A~" + y + 5;";
}
foo will just return 8 but I cannot simply mixin within the main
scope or the scope will return unintentionally.
int x = 3;
mixin(X!("x")) // <- hidden return
Using foo works fine but adds a level of indirection I feel is
unnecessary. The only thing I feel can work is to rewrite X so
that it uses variables with random names to reduce shadowing
issues and to allow X to take a variable name to put the result
in:
auto X(string A, string N)()
{
return "{ int _342sdfs = 4; "~N~" = "~A~" + _342sdfs + 5;}";
}
which complicates things significantly. My hope is that D would
inline the function call.
Ideally I'd like to be able to sort of use the mixin as a
function and simply call it:
val = mixin(X!("x"))();
which I could do by internally using a delegate inside the mixin
auto X(string A)()
{
return "(() { int y = 4; return "~A~" + y + 5; })";
}
except that the mixin syntax does not allow one to use it in an
expression.
Remember that the mixin must be able to see the scope it is mixed
in at so one can't wrap this in a template use it as far as I
know?
Although, one can do
mixin(X!("val", "x"));
which does the ugly work.
It would be nice to be able to get this process to look as much
like normal D code as possible.
the idea is to try to write "local" string mixins that are messy
and not "C'ish" looking in to "C'ish" looking code.
Re: GDC Explorer - an online disassembler for D
On Friday, 21 September 2012 at 03:46:12 UTC, Andrei Alexandrescu
wrote:
I've met Matt Goldbolt, the author of the GCC Explorer at
http://gcc.godbolt.org - a very handy online disassembler for
GCC.
We got to talk a bit about D and he hacked together support for
D by using gdc. Take a look at http://d.godbolt.org, I think
it's pretty darn cool! I'm talking to him about integrating his
work with our servers.
Andrei
Compare a simple C++ to D and the C++ output is far better:
class C
{
int x = 12;
public:
int foo(int y) { return y*x; }
};
int main()
{
C* c = new C();
return c->foo(2);
}
VS
class C
{
int x = 12;
public:
int foo(int y) { return y*x; }
};
int main()
{
C c = new C();
return c.foo(2);
}
operator new(unsigned long)@plt:
jmpQWORD PTR [rip+0x200baa]# 601020 new(unsigned long)@GLIBCXX_3.4>
push 0x1
jmp400450 <.plt>
main:
push rbp
movrbp,rsp
push rbx
subrsp,0x18
movedi,0x4
call 400470
movrbx,rax
movDWORD PTR [rbx],0x0
movrdi,rbx
call 4005bc
movQWORD PTR [rbp-0x18],rbx
movrax,QWORD PTR [rbp-0x18]
movesi,0x2
movrdi,rax
call 4005a4
nop
addrsp,0x18
poprbx
poprbp
ret
nop
C::foo(int):
push rbp
movrbp,rsp
movQWORD PTR [rbp-0x8],rdi
movDWORD PTR [rbp-0xc],esi
movrax,QWORD PTR [rbp-0x8]
moveax,DWORD PTR [rax]
imul eax,DWORD PTR [rbp-0xc]
poprbp
ret
nop
C::C():
push rbp
movrbp,rsp
movQWORD PTR [rbp-0x8],rdi
movrax,QWORD PTR [rbp-0x8]
movDWORD PTR [rax],0xc
nop
poprbp
ret
nopWORD PTR cs:[rax+rax*1+0x0]
nopDWORD PTR [rax+rax*1+0x0]
VS
_Dmain:
push rbp
movrbp,rsp
subrsp,0x10
movrdi,QWORD PTR [rip+0x0]# f <_Dmain+0xf>
call 14 <_Dmain+0x14>
movQWORD PTR [rbp-0x8],rax
movesi,0x2
movrdi,rax
movrax,QWORD PTR [rax]
rex.W call QWORD PTR [rax+0x28]
leave
ret
addBYTE PTR [rax],al
main:
push rbp
movrbp,rsp
subrsp,0x10
movDWORD PTR [rbp-0x10],edi
movQWORD PTR [rbp-0x8],rsi
movrdx,QWORD PTR [rip+0x0]# 16
movrsi,QWORD PTR [rbp-0x8]
movedi,DWORD PTR [rbp-0x10]
call 22
leave
ret
.text.d_dso_init:
push rbp
movrbp,rsp
learax,[rip+0x0]# b <.text.d_dso_init+0xb>
push rax
learax,[rip+0x0]# 13 <.text.d_dso_init+0x13>
push rax
learax,[rip+0x0]# 1b <.text.d_dso_init+0x1b>
push rax
push 0x1
movrdi,rsp
call 26 <.text.d_dso_init+0x26>
leave
ret
the C++ version is more verbose, gives explicit references to
functions and methods while the D version requires you to hunt
and peck.
http://asm.dlang.org/ needs updating
load and save are not working, an example is always compiled in. No code in the input box still shows examples code in the disassembly.
Re: C style callbacks fix for member callbacks
On Sunday, 20 May 2018 at 08:40:57 UTC, MGW wrote:
On Saturday, 19 May 2018 at 23:52:58 UTC, IntegratedDimensions
wrote:
I have a member callback that I want to use as a C callback.
http://www.agner.org/optimize/calling_conventions.pdf
https://www.youtube.com/watch?v=xhDS377mAc4
Sorry, I can't understand Russian(wish I could!). It also does
not seem applicable for my problem. Although It is a useful idea
here(using D in C++).
alias callback = extern(C) int function(const(void) a, void *b,
uint c, void* context);
Where context acts as this.
I would like to assign a D method to this callback.
class
{
callback c;
/*extern(C) static*/ int foo(const(void) a, void *b, uint c,
void* context);
this() { c = cast(callback) }
}
Re: is ==
Furthermore: https://issues.dlang.org/show_bug.cgi?id=3889 Shows real problems. You argue from the side that the bug already exists so we must work around it because we can't go back and "fix things". Who says? D has had breaking changes in the past so it is not a deal breaker. It is also a relatively easy transition because == null is very easy to find and fix. With the mentality that one must always deal with introduced logic bugs that, if fixed, will break old code is insane. The whole point of fixing bugs is to make things work *correctly*. The fact is someone decided it was a good idea to conflate null with some dynamic array BS and that is where all the problems come from. It should have never been done and this issue will persist until someone gets the balls to fix it. After all, how do you know it won't actually make a lot of "buggy" code better?
Re: is ==
On Sunday, 20 May 2018 at 02:09:47 UTC, Jonathan M Davis wrote:
On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via
Digitalmars-d- learn wrote:
Simply require == null as is null and be done with it.
That would be flat out wrong for dynamic arrays, because then
auto result = arr == null
and
int[] nullArr;
auto result = arr == nullArr;
would have different semantics. The way that dynamic arrays are
designed to work even if they're null mucks with this
considerably here.
Do you not see they are different?
You think
arr == nullArr
and
arr == null
are suppose to necessarily be the same semantics? That is
patently false! You should rethink your position on that because
it is wrong. null is a keyword in D and has a very special
meaning and hence that meaning MUST be taken in to account.
There is no harm in making them different. Your logic thinks that
that they should be the same but if you are wrong then your whole
argument is wrong.
for example,
Object o = null;
then
o == null
should not be true even though "null == null" in some sense.
== null is a test of validity. One never checks if null == null
and it is a meaningless case so allowing it as a possibility is
meaningless.
You are treating null as if it is on the same level as objects
and arrays and it is not. By doing so you lose the power of it
being singled out as a keyword.
You can't police programmers minds and get them to program
correctly.
That's true, but making things that are highly likely to be
wrong illegal prevents bugs. e.g.
Not necessarily because you just create more bugs by doing that.
Your son, the bubble boy, then does not develop an immune system
that he should of developed by you trying to protect them from
hurting himself.
You should get out of the business of trying to prevent things
that you don't even know are going to happen. It is a bad mindset
to be in because, for all you know, those things will never
happen. Time is better spent than trying to police everyone from
doing anything wrong. 1. You can't do it. 2. You make things
worse in the long run because who's policing you to keep you from
screwing up?
Do you know how many "bugs" are produced by people who are fixing
"bugs"? We can surely bet more than zero.
while(cond);
is illegal in D precisely because it's error-prone. There are
cases where doing something like that would be perfectly
correct. e.g.
while(++a != b);
but you can do the exact same thing with empty parens
while(++a != b) {}
and all of those bugs with accidentally closing a loop with a
semicolon go away, and you don't lose any expressiveness. The
compiler just forces you to write it in a way that's far less
error-prone.
This is a different problem and therefor not applicable.
Making it illegal to compare the null literal with == also
prevents bug, and you don't lose any expressiveness doing it
either. It's the same kind of logic. Making error-prone
constructs illegal when there's a simple equivalent that isn't
error-prone is good language design, because it prevents bugs
without actually restricting the programmer. It's when the
language starts disallowing things that aren't error-prone
and/or don't have simple equivalents that you start running
into problems with the compiler getting in your way and
treating you like a kid. For simple stuff like this, it
ultimately saves you time and effort without getting in your
way. At most, you occasionally have to replace foo == null with
foo is null or foo.length != 0, and it potentially saves you
hours of effort tracking down a subtle bug.
- Jonathan M Davis
You certainly do lose expressiveness. You loose elegance because
you cannot express logically related things in a logically
related way.
The problem is the WHOLE reason it is error prone is from who
ever decided the dynamic array syntax of == null would not
compare it the same way it does everything else.
Basically someone thought they were going to be fancy and treat
== null as the same as an allocated 0 length array. That was the
problem from the get go.
== null should have a very specific and consistent meaning and
someone decided to change that in an irregular and inconsistent
meaning and now we have less elegance in the language than we
could.
The reason why you are saying it is buggy is PRECISELY because of
what was done wrong. Programmers assume that == null means the
same thing it does everywhere else, but LO AND BEHOLD! Not in
that one special case and if they don't know about that special
case they hit the "bug".
See, what you call bugs is really the programmers failing to know
the special case that was created. The special case that really
had no reason to be a special case. So, in fact, who ever decided
on the rules here created more problems than they solved.
Any time you create special cases you create complexity and that
is what c
Re: is ==
On Sunday, 20 May 2018 at 00:19:28 UTC, Jonathan M Davis wrote: On Saturday, May 19, 2018 17:50:50 IntegratedDimensions via Digitalmars-d- learn wrote: So, ultimately what I feels like is that you are actually arguing for == null to be interpreted as is null but you don't realize it yet. Not really, no. Having foo == null be rewritten to foo is null in the non-dynamic array cases should be fine except for the fact that it's then a terrible habit to be in when you then have to deal with dynamic arrays. Using foo == null with dyanmic arrays is an enormous code smell, because the odds are extemely high that the programmer thinks that they're checking if the dynamic array is null when that's not what they're doing at all. IMHO, it should definitely be an error to use == with null and dynamic arrays because it is such a big code smell. Either the code should be using is to check whether the array is null, or it should be checking length. It should never be using == with null. But unfortunately, the compiler is completely backwards about this and treats it as an error with pointers and references but allows it with dynamic arrays. If the compiler were improved to just replace == with is in the cases that it currently treats as illegal, then that would be fine if it then treated it as illegal with dynamic arrays. But as it stands, it is still more efficient to use is with call references, so encouraging the programmer to use is is benefical, and it encourages the programmer to get in the habit of not using == with null, since it's a terrible habit to be in with dynamic arrays. But actually making it illegal for dynamic arrays would be a much better approach. If it were up to me, it would just be illgal to use == with null in general, because that's really the way it should be with dynamic arrays, and then the language would be consistent about it. But instead, the compiler screams in the case that matters far less and allows it in the case that is clearly bad. So, it's inconsistent in a dumb way. At least if it were inconsistent by allowing it for pointers and references while disallowing it for arrays, it would be prventing it in the case that truly matters, but instead, what we have is just dumb. - Jonathan M Davis Let D be a dynamic array, O a pointer or object: | Conceptually | in D D == null Invalid Valid D is null Valid Valid O == null Valid Invalid O is null Valid Valid Right? So what you are saying is you want to create 2 more invalids in the table to satisfy some weird logic which requires the programmer to remember special cases rather than make them all valid and easy to remember even though it can be done and make sense. In fact, the 2nd invalid makes sense and should be allowed so really you want to create 3 invalids for the price of one. Simply require == null as is null and be done with it. You can't police programmers minds and get them to program correctly. If you had a kid, do you box them up in a bubble room and not let them play because they might hurt themselves? How people learn is by making mistakes. It is better to provide a logical foundation that is consistent rather than produce corner cases to handle some corner case that was created to handle another corner case because someone handled a corner case.
C style callbacks fix for member callbacks
I have a member callback that I want to use as a C callback.
This is impossible due to the `hidden this` passed as the "first"
parameter.
The callback already makes it's last value a user pointer which I
use as a "this".
If I make my method static extern(C) then there is no crash and
everything works. The problem is that it is now a static function
within the class which I want to avoid.
Because there is actually a "this pointer" I can make it a member
function and everything works as long as the calling convention
is right.
I was initially wrapping the callback in a delegate that made it
all work out but I want to avoid that level of indirection since
it should not be necessary.
I have tried manually reversing the arguments, using various
calling conventions, etc but everything crashes except when I use
extern(C) static without modifying the order.
extern(C) static foo(a,b,c,d)
puts the parameters on the stack as d,c,b,a
foo(a,b,c,d)
is d,c,b,a,this (? The ABI does not make it clear what order is
pushed on the stack. It uses the terminology "passes" and I
assume that the calling convention is C'ish although extern(C)
matters).
works
extern(C) static foo(a,b,c,d)
does not work
static foo(d,c,b,a)
So something else is going on
"The last parameter is passed in EAX rather than being pushed on
the stack if the following conditions are met:
It fits in EAX.
It is not a 3 byte struct.
It is not a floating point type.
"
Can someone clarify the exact calling convention process for C vs
D along with any potential solutions to the above problem(using
static is not a solution).
Just to make sure we are on the same page:
class
{
void extern(C) static foo(a,b,c,mythis);
}
works while
class
{
void extern(C) foo(a,b,c);
}
fails.
class
{
void foo(c,b,a);
}
also fails.
Re: Real Int24
On Saturday, 19 May 2018 at 18:19:35 UTC, IntegratedDimensions
wrote:
Is there any way to create an int24 type that behaves just like
any other built in type without having to reimplement
everything?
In fact, what I'd like to do is create an arbitrary type:
struct atype(T)
{
}
where atype(T) is just a "view" in to N_T bits interpreted as T,
an enum.
If T is bit, then the N = 1 and the interpretation is 1 bit.
If T is byte, then the N = 8 and the interpretation is 7 bits
followed by 1 signed bit.
If T is int24, then the N = 24 and the interpretation is 23 bits
followed by 1 signed bit.
The idea is the storage of atype is exactly N bits. If this is
not possible due to boundary issues then N can always be a
multiple of 8(which is for my use cause is the smallest).
The main thing is that I would like to be able to use atype as if
it were a built in type.
If N = 24, 3 bytes, I want to be able to create arrays of
atype!int24[] which work just as if they were arrays of bytes
without any exception or special cases.
atype!byte would be equivalent to byte and reduce to the compiler
internals. I'm not looking to create a "view" of an array. I want
a standalone type that can behave as all the desired types
needed, which is most of the numerical types of D and some of the
ones it neglected like 24-bit ints, 48-bit ints, etc. Ideally,
any type could be used and the "most optimal" code is generated
while being able to use the types using the standard model.
Real Int24
Is there any way to create an int24 type that behaves just like any other built in type without having to reimplement everything?
Re: is ==
On Saturday, 19 May 2018 at 01:31:38 UTC, Jonathan M Davis wrote: On Friday, May 18, 2018 23:53:12 IntegratedDimensions via Digitalmars-d- learn wrote: Why does D complain when using == to compare with null? Is there really any technical reason? if one just defines == null to is null then there should be no problem. It seems like a pedantic move by who ever implemented it and I'm hoping there is actually a good technical reason for it. Because == is pretty much never what you want to do with null. How much it matters depends on the types involved, but if you really want to check for null, is is definitely the right thing to use. In the case of pointers and references, is checks that they're pointing to the same thing. So, foo is null directly checks whether the reference or pointer is null. On the other hand, if you use ==, it's calling some form of opEquals. For pointers, that should generate identical code, but for class references, it means calling the free function opEquals. That function will check whether the references are null before calling opEquals on either of the class objects, but it does add unnecessary overhead (which, as I understand it, the compiler is unfortunately not currently able to optimize away) and provides no benefit over checking with is. Now, where is vs == _really_ matters (but unfortunately, the compiler does not complain about) is with dynamic arrays. If you do arr is null then the compiler will check whether the array's ptr is null. So, something like "" is null would be false. However, if you use ==, then it compares the length of the array and then only compares the ptrs if the length is non-zero. So, "" == null is true. So, with dynamic arrays, using == with null is a huge code smell. It _may_ be exactly what the programmer intends, but the odds are pretty high that they just don't properly understand the difference between is and ==, and they meant to be checking whether the array was actually null but just ended up checking whether its length was zero (which won't matter for some code but will cause subtle bugs in any code that treats null as special - e.g. if that is used to indicate that the array had not been given a value). Now, because of how == treats null like empty, it _is_ a bit risky to try and treat null as special with arrays, but anyone wanting to be clear in their code should either be checking null with is (in which case, they clearly care about null and not empty), or if they care about length == 0, they should either be calling empty on the array or explicitly checking the array's length, since that's what they care about. Much as having == work with null arrays avoids issues with segfaults due to an array be unitialized as well as avoids needing to give memory to an array just to have it be empty, you pretty much never actually care whether an array == null. You either care that its ptr is null (in which case, is checks that), or you care about whether its length is 0 (in which case empty or directly checking length checks that). arr == null is just unclear and likely buggy. So really, there are _zero_ advantages to comparing null with ==. Using == with null risks adding extra overhead, and it often makes the code less clear. On the other hand, using is makes it crystal clear what you mean and then does exactly what you mean - check whether the variable is actually null. So, maybe the compiler is being a bit pedantic by insisting that you use is rather than ==, but you really should be using is and not == when checking for null. - Jonathan M Davis I don't see your point. You claim that one should never use == null for whatever reason and that it is "wrong". So, why are you allowing wrong things in a language that can easily be fixed? Just reinterpret == null as is null and be done with it! This fixes the wrong and everyone can live happily ever after. Your logic is the same how people "ban" certain words like faggot. They don't like them for some reason, decide that no one should use it any more, and create a new word that essentially means the same thing... and it results in a loop where that new word then eventually gets "banned". == vs is might not be quite as extreme, maybe is will be the final "word". But if == null is banned by the compiler why the hell not just reinterpret to mean is null internally and be done with it and allow the syntax since it is so common? The only pitfalls is pasting code from other languages that might have a different interpretation, but those problems always exist since the languages are different. Your reasons for arrays is not good enough. First, not all types are arrays so you are banning a whole class of valid types for one case. That case, you say, is almost never meant anyways(that is, using == null is really meant as is null). So, ultimately wha
Re: is ==
On Friday, 18 May 2018 at 23:58:18 UTC, Uknown wrote:
On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions
wrote:
Why does D complain when using == to compare with null? Is
there really any technical reason? if one just defines == null
to is null then there should be no problem. It seems like a
pedantic move by who ever implemented it and I'm hoping there
is actually a good technical reason for it.
D only complains of this when you use ref types (classes or
AAs). For e.g:
--- test.d
void main()
{
int * p;
assert (p == null && p is null);
class C
{
int x;
}
C c;
assert (c is null);
assert (c == null); //error, c is a reference, so there is
confusion between opEquals and null check
}
---
or pointers.
is ==
Why does D complain when using == to compare with null? Is there really any technical reason? if one just defines == null to is null then there should be no problem. It seems like a pedantic move by who ever implemented it and I'm hoping there is actually a good technical reason for it.
Re: do not include sc.ini in zip files!
On Thursday, 17 May 2018 at 08:53:06 UTC, Vladimir Panteleev wrote: On Thursday, 17 May 2018 at 07:38:50 UTC, IntegratedDimensions wrote: Any custom modification swill overwrite the original sc.ini file. The compiler should copy(rename) or create the file on demand when it is ran and does not exist in the same path as the compiler. Not detracting from your argument, but according to https://dlang.org/dmd-windows.html#sc-ini , you can place your custom version in %HOME%/sc.ini. This may be a suitable solution. While it has some overhead and pollutes the environment, it at least offers a working alternative unlike other (non)"solutions". It would be better if HOME wasn't so general since other applications could collide with it in usage. DMD_HOME would be better or in addition to.
do not include sc.ini in zip files!
Any custom modification swill overwrite the original sc.ini file. The compiler should copy(rename) or create the file on demand when it is ran and does not exist in the same path as the compiler. This way one can unzip over a previous install without losing the original sc.ini file. It is a pain to have to remember to back it up every time(given if one updates slowly). That or simply let an alternative "sc.ini" file be used if it exists. e.g., if sc-main.ini exists then it will use that first and if not then it defaults to sc.ini. sc-main.ini is not included in the distribution.
Re: DIP 1011 library alternative
On Tuesday, 15 May 2018 at 21:25:05 UTC, Andrei Alexandrescu wrote: Hello, I was reviewing again DIP 1011 and investigated a library solution. That led to https://gist.github.com/run-dlang/18845c9df3d73e45c945feaccfebfcdc It builds on the opening examples in: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md I'm displeased at two aspects of the implementation: * Perfect forwarding is tedious to implement: note that makeDelegate hardcodes void as the return type and (int, float) as parameter types. Ideally it should accept any parameters that the alias passes. * Pass-by-alias and overloading interact poorly. Does anyone know how to refer by alias to one specific overload? Thanks, Andrei While you are at it, could you add a linkage type that lets one specify marshaled member function callbacks for interfacing with callbacks in windows API? In many windows callbacks they require specifying a function pointer for a standard winapi function. The problem is that we cannot pass methods of objects to windows functions wanting a callback since the methods use the calling convention of passing in object reference as the first parameter and expects that value to point to the object the method is acting in. I have hacked together thunking using the standard methods to allow member functions but it is not pretty. You can get more details of the problem here: https://www.codeproject.com/Articles/16785/Thunking-in-Win-Simplifying-Callbacks-to-Non-sta The idea would be to allow marking methods in a certain way which thunks them automatically for passing in to winapi callbacks almost as seamless as passing a static function. It's a little tricky to do because the object reference as to be stored somewhere and retried correctly. In my hacked code I create a new function on the heap for each callback and store the object reference along side it. Inside the function it gets it's reference not from the hidden this parameter but from from the stored object value. The real problem is the argument layout. Winapi will expect the first argument to be it's own but it stores the value in the object reference parameter. All these nuisances can be hidden by compiler magic.
Re: Dependency injection pattern
On Sunday, 13 May 2018 at 07:42:10 UTC, Suliman wrote:
Could anybody give small example of Dependency injection
pattern? I googled about it, but found only C# examples and I
am not quite sure how to use them.
Also I would like get some explanation/comments for code.
Dependency injection is explicit dependencies are injected in to
an object for use by the creator of the object rather than hard
coding dependencies in to the object.
For example, if you are creating an object that will lightly
depend on an interface I then you can the interface and require
that the object for the interface be injected(specified) by the
user of the object.
class X
{
I i;
void foo() { /* uses i */ };
}
Then X.i = _i; is a dependency injection of _i so that X uses _i.
Usually one does not want the dependency to be freely changed as
to avoid changing a dependency in the middle of it being used.
Various schemes can be create to avoid these issues such as
allowing injection only during construction or some special
synchronization techniques to avoid usages. e.g.,
void foo() { I _i = i; /* uses _i */ };
Then reassignment won't change the dependency when a function is
using it.
Whatever means, the idea is simple: One does not want to hard
code dependencies directly so that refactoring code is ultimately
easier. Dependencies can be injected in to the working code by
the user. This makes the code depend on the type of the
dependency so any specific dependency can be injected.
Top answer here says pretty much exactly what I'm saying:
https://stackoverflow.com/questions/3058/what-is-inversion-of-control?utm_medium=organic_source=google_rich_qa_campaign=google_rich_qa
Re: auto: useful, annoying or bad practice?
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote: I'll freely admit I haven't put a ton of thought into this post (never a good start), however I'm genuinely curious what people's feeling are with regards to the auto keyword. Speaking for myself, I dislike the auto keyword. Some of this is because I have a preference for static languages and I find auto adds ambiguity with little benefit. Additionally, I find it annoying that the phobos documentation relies heavily on auto obscuring return types and making it a bit more difficult to follow what is happening which gives me a bad taste for it. Having said, the thing that really started my thinking about this was this post I made: https://forum.dlang.org/thread/fytefnejxqdgotjkp...@forum.dlang.org Where in order to declare a public variable for the RedBlackTree lowerBound/upperBound methods I had to fall back on using the ReturnType template to declare a variable. Jonathan was nice enough to point me in the right direction and maybe there's a way to do this without having to fall back on ReturnType. However this made be wonder if reliance on auto could discourage API writers from having sane return types. So I'm curious, what's the consensus on auto? Auto is useful... simple as that. If you don't like it don't use it. If you get confused about it then beef up your game in analysis. Obscurity can be done many ways so complaining about one specific way is not very thought out. myfunkytypethatyoudontknowabouthiddenthrough100layersofabstraction foo();
D4M In D?
http://www.mit.edu/~kepner/D4M/ Anyone?
Re: Error: module `hello` is in file 'hello.d' which cannot be read
On Friday, 4 May 2018 at 23:29:12 UTC, Alex wrote:
Hi
I just installed D on my windows 10 and want to try to compile
a hello world. My source is a classical
import std.stdio;
void main() {
writeln("Hello, World!");
}
And I try to compile and get
C:\D>dmd hello.d
Error: module `hello` is in file 'hello.d' which cannot be read
import path[0] = C:\D\dmd2\windows\bin\..\..\src\phobos
import path[1] = C:\D\dmd2\windows\bin\..\..\src\druntime\import
What do I do wrong ?
D is installed at de root of C:, and the hello.d source code is
at C:\D\dmd2\sources.
Thank you to you
Alex
You need to make sure hello.d is in the current dir
dir C:\D
does hello.d show up?
If not, then dmd can't find it and you have to tell it where it
is or be in the right location.
type
dmd ThereIsNowFileHere12342123242231231412.d
and you will get the same error message.
LDC phobos2-ldc.lib(json.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86'
trying to compile a simple program in x86. Compiles fine in dmd and ldcx64. Seems like ldc is using the wrong lib for some reason? phobos2-ldc.lib(json.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86' Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\link.exe failed with status: 1112 Tried replacing the x64 dir with the x86 and it didn't change so it isn't the library arch best I can tell. Maybe this is a cross compilation issue?
Re: How to curl!
On Wednesday, 2 May 2018 at 03:03:19 UTC, ikod wrote: On Wednesday, 2 May 2018 at 00:04:49 UTC, IntegratedDimensions wrote: On Tuesday, 1 May 2018 at 23:35:42 UTC, Arun Chandrasekaran wrote: [...] Ok, first try: Unhandled exception: object.Exception can't complete call to TLS_method at requests\ssl_adapter.d(248) which says it can't find the lib. I renamed ssleay32.dll to libssl32.dll and it then passed. I am getting http 404 error though ;/ I turned off cert though, which may be the reason, I have no idea. Seems to be working through. Did you try to use full path to cacert.pem? That seemed to work. Why would it not look in the current directory by default? Maybe something to add?
Re: How to curl!
On Tuesday, 1 May 2018 at 23:35:42 UTC, Arun Chandrasekaran wrote: On Tuesday, 1 May 2018 at 21:57:22 UTC, IntegratedDimensions wrote: Trying to curl basic stuff but std.net.curl isn't cooperating: This is one of the reasons I hate D ;/ I've spent more time trying to get std.net.curl to do something that just works from the command line. std.net.curl is not quite up to date when compared to the curl command. It is not useful any non-trivial stuff. Right now I'm using ikod's dlang-requests[1] and I'm quite happy with it. I would recommend you to try it. [1] https://github.com/ikod/dlang-requests Ok, first try: Unhandled exception: object.Exception can't complete call to TLS_method at requests\ssl_adapter.d(248) which says it can't find the lib. I renamed ssleay32.dll to libssl32.dll and it then passed. I am getting http 404 error though ;/ I turned off cert though, which may be the reason, I have no idea. Seems to be working through.
Re: How to curl!
On Tuesday, 1 May 2018 at 23:02:39 UTC, Dr.No wrote: On Tuesday, 1 May 2018 at 22:51:01 UTC, IntegratedDimensions wrote: [...] those dlls: libeay32.dll libssl32.dll ssleay32.dll I'm sure they would be installed with whatever [...] I don't think so. IIRC, when I used D+curl I needed to download them manutally. This is always the case with Qt. Even using windeployqt with --webkit2 flag I still need to copy those dlls to application binary folder. [...] It isn't always the case if the dll is dynamic loaded, it might fail quietly, for example, if you deploy an Qt application with QWebKit missing those Open SSL dlls, an page with https protocol just doesn't open and didn't show any error at all. To find out whether some referenced dll by your executable is missing, people use Dependence Walker: http://www.dependencywalker.com/ I don't think this is the problem. If I use get on https://www.google.com it works fine but if I use get on https://www.googleapis.com/youtube/v3/channels it fails so it is site dependent.
Re: How to curl!
On Tuesday, 1 May 2018 at 22:08:50 UTC, Dr.No wrote: On Tuesday, 1 May 2018 at 21:57:22 UTC, IntegratedDimensions wrote: Trying to curl basic stuff but std.net.curl isn't cooperating: curl "https://www.googleapis.com/youtube/v3/channels; -G -d part=contentDetails -d forUsername=test -d key=somekey [...] Just a wild guess, do you have the SSL dlls in the same folder as your executable or (less likely) in your PATH? What SSL dlls? I'm sure they would be installed with whatever installation uses them. ssleay32.dll comes with dmd2 and it is in the path, if that is what you are talking about. If a dll was missing though and that was the problem then it needs to state that it is a missing dll rather than some other issue.
How to curl!
Trying to curl basic stuff but std.net.curl isn't cooperating:
curl "https://www.googleapis.com/youtube/v3/channels; -G -d
part=contentDetails -d forUsername=test -d key=somekey
import std.stdio;
import std.net.curl;
int main(string[] argv)
{
auto http = HTTP();
http.caInfo("cacert.pem"); // cacert.pem installed in the bin dir
http.handle.set(CurlOption.ssl_verifypeer, 1);
auto content =
post("https://www.googleapis.com/youtube/v3/channels;, ["part" :
"contentDetails", "forUsername" : "test", "key" : "somekey"],
http);
return 0;
}
I either get the error
Unhandled exception: std.net.curl.CurlException Peer certificate
cannot be authenticated with given CA certificates on handle at
std\net\curl.d(4343)
or, when verifypeer is 0,
Unhandled exception: std.net.curl.HTTPStatusException HTTP
request returned status code 404 (Not Found)
But the command line version works fine. (of course, if you want
to test you must use a valid key and youtube user name.
This is one of the reasons I hate D ;/ I've spent more time
trying to get std.net.curl to do something that just works from
the command line.
Re: Found on proggit: Krug, a new experimental programming language, compiler written in D
On Friday, 27 April 2018 at 00:03:34 UTC, H. S. Teoh wrote: On Thu, Apr 26, 2018 at 07:14:17PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: On 04/26/2018 06:47 PM, H. S. Teoh wrote: > > If "less is more" were universally true, we'd be programming > in BF instead of D. :-O (Since, after all, it's > Turing-complete, which is all anybody really needs. :-P) > Yea. Speaking of which, I wish more CS students were taught the the inherent limitations of "Turing-complete" vs (for example) "Big-O". There's fr too many people being taught "Turing-complete means it can do anything" which, of course, is complete and total bunk in more (important) ways than one. Actually, Turing-complete *does* mean it can do anything... well, anything that can be done by a machine, that is. There are inherently unsolvable problems that no amount of Turing-completeness will help you with. The problem, however, lies in how *practical* a particular form of Turing-completeness is. You wouldn't want to write a GUI app with lambda calculus, for example, even though in theory you *could*. (It would probably take several lifetimes and an eternity of therapy afterwards, but hey, we're talking theory here. :-P) Just like you *could* write basically anything in machine language, but it's simply not practical in this day and age. And actually, speaking of Big-O, one thing that bugs me all the time is that the constant factor in front of the Big-O term is rarely considered. When it comes to performance, the constant factor *does* matter. You can have O(log n) for your algorithm, but if the constant in front is 1e+12, then my O(n^2) algorithm with a small constant in front will still beat yours by a mile for small to medium sized use cases. The O(log n) won't mean squat unless the size of the problem you're solving is commensurate with the constant factor in the front. You can sort 5 integers with an on-disk B-tree and rest assured that you have a "superior" algorithm, but my in-memory bubble sort will still beat yours any day. The size of the problem matters. Not to mention, constant-time setup costs that's even more frequently disregarded when it comes to algorithm analysis. You may have a O(n^1.9) algorithm that's supposedly superior to my O(n^2) algorithm, but if it takes 2 days to set up the data structures required to run your O(n^1.9) algorithm, then my O(n^2) algorithm is still superior (until the problem size becomes large enough it will take more than 2 days to compute). And if your O(n^1.9) algorithm has a setup time of 10 years, then it might as well be O(2^n) for all I care, it's pretty much useless in practice, theoretical superiority be damned. And that's not even beginning to consider practical factors like the hardware you're running on, and why the theoretically-superior O(1) hash is in practice inferior to supposedly inferior algorithms that nevertheless run faster because they are cache-coherent, whereas hashing essentially throws caching out the window. Thankfully, recently there's been a slew of papers on cache-aware and cache-oblivious algorithms that are reflect reality closer than ivory-tower Big-O analyses that disregard reality. I see the same thing in other areas of CS, too, like parser theory. The formal CS material makes it sound as if LR parsing is more or less every bit as powerful as LL (and they often straight-up say so in no uncertain terms), but then they all gloss over the fact that: That's ONLY true for "detecting whether an input does or doesn't match the grammar", which is probably the single most UNIMPORTANT characteristic to consider when ACTUALLY PARSING. Outside of the worthless "does X input satisfy Y grammar: yes or no" bubble, LL-family is vastly more powerful than LR-family, but you'd never know it going by CS texts (and certainly not from those legendary-yet-overrated Dragon texts). Well, LR parsing is useful for writing compilers that tell you "congratulations, you have successfully written a program without syntax errors!". What's that? Where's the executable? Sorry, I don't know what that word means. And what? Which line did the syntax error occur in? Who knows! That's your problem, my job is just to approve or reject the program in its entirety! :-P (And don't get me started on computability theory courses where the sole purpose is to explore the structure of the hierarchy of unsolvable problems. I mean, OK, it's kinda useful to know when something is unsolvable (i.e., when not to waste your time trying to do something that's impossible), but seriously, what is even the point of the tons of research that has gone into discerning entire *hierarchies* of unsolvability?! I recall taking a course where the entire term consisted of proving things about the length of proofs. No, we weren't actually *writing* proofs. We were proving things *about* proofs, and I might add,
Re: Making an .exe that executes source file inside itself.
On Friday, 27 April 2018 at 14:57:34 UTC, BoQsc wrote: On Friday, 27 April 2018 at 04:30:32 UTC, IntegratedDimensions wrote: On Thursday, 26 April 2018 at 06:18:25 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 20:44:10 UTC, u0_a183 wrote: On Wednesday, 25 April 2018 at 19:54:26 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M Davis wrote: [...] Thank you Jonathan for a response. I was aware of this, and it certainly perfectly works where command line/terminal interface is the main tool to control the system, a good example would be linux/gnu distributions and macOS. However in Windows while installing D language, I noticed that .d source file extension is not associated with neither D compiler (dmd.exe) nor D script interpretator (rdmd.exe) So they can't be ran directly by clicking on those, nor they have any icons that show that these source codes are actually executable. This is a huge problem, because people that are not aware of D language migh be harder to understand that source script could be executable, at least - without help from some more experienced user. If the purpose is to make scripts run by clicking them you can assign a file type to .d files. On Windows 10. https://www.digitaltrends.com/computing/how-to-set-default-programs-and-file-types-in-windows-10/ Doing so would make the script engine the default program instead of a text editor so you might not want to. Or maybe assign .dxe and changing the filename before running. Executable has executable file type for a reason - it self-implies that the main function of the file - is to be executed. The problem with making source code files executable is that, source code files, might not always be monolithic executable code, but a part of a bigger interconnected program. That would lead to partily working program execution, and most of the times guess work of whether source code file was supposed to be executed. This is wrong. All code must be included. All library source code is included. If this is infeasible then simply the binaries are included. It would be no different than dynamic linking that already exists. It doesn't create any new problems. Sure certain things would need to be worked out properly to optimize the experience, but that is obvious. One can't make everything perfect though and one shouldn't expect it... The clear alternative would be: .exe file on which, if rightclicked - would open context menu showing posibility of "edit/improve this executable". Which would not create additional problem mentioned above. Yes, all the source code and required source code to make everything work must be included. And where would all the code mentioned before should be stored? It must be stored in a an single self extracting archive, self executing archive, that is self-implying that it is an executable code, which means it can't be .d file extension, but an .exe file extension. (or any other, if anyone come up with more common or self explaining extension name) If we use the same .d file extension on this self-executable, self-extracting archive, it would confused people weather it is executable or some novice programmer's written module/script. No, it would have to be an exe on windows. an exe is basically a self executing container. Almost all exe's only contain the binary but they can contain data. For example, zip files can be saved as self-unzipping executable. It is not a big deal to package the data in the exe and make it all work. Initially, it is not necessary to worry about. What happens is that the actual initial binary that will run will essentially decide what needs to be done and unpack everything and deal with it. You can think of the exe as a small file system that contains all the files necessary and a binary that handles whatever needs to be done which is run by the OS. Several binaries in the file would be things like the IDE/debugger and the compiled source code. If the user just wants to run the app like any normal app then the compiled source code would be extracted either to a temp exe file or to memory and ran. (so the initial process just does some unpacking and passes control) If debugging and modification is to be done then the initial process will have to do more work such as compile the source with debugging symbols, special hooks, and all that. The files would have to be extracted in memory or on disk. The ide would be ran, etc. For example, android apps are actually special zip files. All of this stuff is childs play. The real work is having a proper design that integrates everything well. Nothing would be technically challenging but just a lot of work to get everything done. I do think that apps that were designed to be used this way would need to be structured and designed in a way that makes it conducive to debugging and modifying easily and quickly.
Re: Making an .exe that executes source file inside itself.
On Thursday, 26 April 2018 at 06:18:25 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 20:44:10 UTC, u0_a183 wrote: On Wednesday, 25 April 2018 at 19:54:26 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M Davis wrote: On Wednesday, April 25, 2018 19:19:58 BoQsc via Digitalmars-d-learn wrote: So there has been idea I've got for around few months now: making a software which executable would contain a source file. A software that anyone could modify by opening an executable and quickly change a few lines of it, rerun an executable, see the changes. Could this be easily possible with D language, considering that sources files can be ran without long slow compilation process? The normal way to do that is to just write a script. In the case of D, you can just use rdmd to do it. e.g. if you're on a POSIX system, just put #!/usr/bin/env rdmd at the top of your .d file and chmod it so that it's executable, and it'll run like any other script. - Jonathan M Davis Thank you Jonathan for a response. I was aware of this, and it certainly perfectly works where command line/terminal interface is the main tool to control the system, a good example would be linux/gnu distributions and macOS. However in Windows while installing D language, I noticed that .d source file extension is not associated with neither D compiler (dmd.exe) nor D script interpretator (rdmd.exe) So they can't be ran directly by clicking on those, nor they have any icons that show that these source codes are actually executable. This is a huge problem, because people that are not aware of D language migh be harder to understand that source script could be executable, at least - without help from some more experienced user. If the purpose is to make scripts run by clicking them you can assign a file type to .d files. On Windows 10. https://www.digitaltrends.com/computing/how-to-set-default-programs-and-file-types-in-windows-10/ Doing so would make the script engine the default program instead of a text editor so you might not want to. Or maybe assign .dxe and changing the filename before running. Executable has executable file type for a reason - it self-implies that the main function of the file - is to be executed. The problem with making source code files executable is that, source code files, might not always be monolithic executable code, but a part of a bigger interconnected program. That would lead to partily working program execution, and most of the times guess work of whether source code file was supposed to be executed. This is wrong. All code must be included. All library source code is included. If this is infeasible then simply the binaries are included. It would be no different than dynamic linking that already exists. It doesn't create any new problems. Sure certain things would need to be worked out properly to optimize the experience, but that is obvious. One can't make everything perfect though and one shouldn't expect it... The clear alternative would be: .exe file on which, if rightclicked - would open context menu showing posibility of "edit/improve this executable". Which would not create additional problem mentioned above.
Re: Making an .exe that executes source file inside itself.
On Wednesday, 25 April 2018 at 19:19:58 UTC, BoQsc wrote: So there has been idea I've got for around few months now: making a software which executable would contain a source file. A software that anyone could modify by opening an executable and quickly change a few lines of it, rerun an executable, see the changes. Could this be easily possible with D language, considering that sources files can be ran without long slow compilation process? I had a similar idea a few months ago too, coincidence? The idea is that all apps have the source code embedded so that they can be debugged and modified by the user at will. Each app has a built in IDE and debugger(or can trigger an external one for space). When an error occurs it will jump to the debugger for debugging purposes. If some functionality is to be modified(e.g., change the size of a button or add some new feature) the user can trigger the IDE(hot key) to proceed. The point of having it all self contained is to allow future revision and debugging without having to worry about version issues. The point of the debugging is so the user can fix bugs that plague software. While on the whole most software may work for most users, it is very annoying when some minor bug prevents a program from working for a specific user. Many more people know how to program than ever and it will only become more and more common. Also, with such capabilities, the user can add additional functionality. It is very annoying when programs don't support simple stuff. A few lines of code could make the program much more effective for a user that wants to do something that was not thought of if they could just add it. e.g., even just display something, change the location of a widget, or modify how a text file is read so it can support a new format. One can argue that platforms such as Linux make this easy... but only marginally. If one get actually get the code to compile without having to waste many hours, one must also generally sift through the code to find the relevant parts then try and understand them. Usually because of the trial and error process is long this generally is a deterrent for "normal" people with "normal" lives. If apps are properly structured with such goals in mind then it would be of great benefit, although only a few of us like you and me have the wherewithal to extrapolate out. It would not be difficult to do(it is more about organization than about technological problem solving). With proper ide design, debugger, and such, one could make app writing self contained, so to speak. That is, the IDE and debugger are used directly to write the program instead of using the traditional methods such as vim, emacs, visual studio, coedit, etc. What is packaged in an binary are the IDE Debugger Profiling Source Code(with history, VCS included) Compiled Code(possibly optimized version) Debugging Data Scripting Generally, without debugging, the executable just runs the compiled code as if it were a normal app. When triggered, the ide/debugger can be brought up that takes over and displays the desired source code(triggers can be used). I believe the main issues for proper development would be the ability for quick code replacement(hot swapping, injection, etc) which is tricky since some code would require a full restart which will slow things down. Most of the other programs are just gluing everything together and providing certain mechanisms that allow for robustness such as being able to replace the IDE or debugger, extract the source code for repackaging. While it would be time consuming to implement well it would be very useful. There are many many times I have used programs that simply do not function correctly or are missing simple functionality that would take me a just a few minutes to write a few lines of code to fix. Having the above would make it possible to do. One could also then "upload" patches/fixes/enhancements to the cloud or download others. This way people can tailor applications to their own use rather than being stuck with what the developers(which generally are somewhat clueless as their main goal is to ship the product rather than provide all the functionality their users want).
