Re: dlang vs crystal-language
On Thursday, 29 April 2021 at 05:41:45 UTC, Imperatorn wrote: Crystal has no installer for Windows Is this a strength or a weakness? (SCNR)
Re: What's a good approach to DRY with the block code of a case-statement?
I'd recommend you to use templates with alias parameters but you
mentioned that you need to retain function context(for gotos,
continue, break, etc...)
One thing you could do is mix the ugly mixin solution with the
good one:
```D
//inside the function, so that you can access locals
pragma(inline, true)
string getDRYstr(T, parameters...)() {
static assert(__ctfe);
string mixedinstr;
mixedinstr ~= /*code*/;
static if(/**/){mixedinstr ~= /*code*/;}
//...
mixedinstr ~= "break;";
return mixedinstr
}
```
There is no doubt that it is an ugly solution but the time saved
not copy-pasting code could be worth it.
Re: dlang vs crystal-language
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Crystal has no installer for Windows
Re: serve-d and emacs
On 26.04.21 21:13, WebFreak001 wrote:
On Monday, 26 April 2021 at 18:45:08 UTC, Christian Köstlin wrote:
Does anybody use serve-d with emacs (lsp-mode or eglot)?
I would love to see the configuration!
Kind regards,
Christian
if you configure it yourself, feel free to share the configuration and
maybe PR it to serve-d repo.
Basic setup should be quite easy, see vim for reference:
https://github.com/Pure-D/serve-d/blob/master/editor-vim.md
I finally got it working for me.
Its a little tricky, because the basic setup works e.g. with emacs 27.2
or newer, but not with 27.1.
All that is needed (if you have the right emacs version and use straight
for installing packages) is:
(use-package d-mode
:straight t)
(use-package eglot
:straight t
:init (progn
(add-hook 'd-mode-hook 'eglot-ensure)
))
(add-to-list
'eglot-server-programs
'(d-mode . ("PATH_TO_SERVE_D/serve-d")))
With a plain emacs installation the following should work:
(require 'package)
(add-to-list 'package-archives '("melpa" .
"https://melpa.org/packages/;) t)
(package-initialize)
(package-refresh-contents)
(package-install 'project)
(package-install 'd-mode)
(package-install 'eglot)
(require 'project)
(require 'd-mode)
(require 'eglot)
(add-to-list
'eglot-server-programs
'(d-mode . ("FULL_PATH_TO_SERVE_D")))
(add-hook 'd-mode-hook 'eglot-ensure)
(One emacs restart might be necessary, as there is a conflict of version
for the dependency "project".
Kind regards,
Christian
dlang vs crystal-language
What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk.
Re: vibe-core sporadic internal errors
On 4/27/21 11:48 AM, Steven Schveighoffer wrote: I suspect vibe-core or event core may have some subtle bugs in them that are not easily repeatable, but often result in half-rendered web pages. Has anyone else seen this? I recently updated to the latest vibe-core and vibe to see if the problem goes away and it doesn't. A log of the exceptions isn't super helpful: ``` Error occurred while accessing /management/sales/translate_option: code 500, (Internal Server Error) Stack Trace: Internal Server Error ``` So I have figured out a couple things here. 1. I started building with `-b plain`, which removes the -debug flag from the compiler (for a long time, I didn't know this was the default for dub). Inadvertently, this made my exception printing result in the above instead of a full stack trace (which I was used to). I now print the stack trace even with -b plain, but my executable is down from 83MB to 35MB! 2. With the full stack trace, I determined that it's not vibe-d, but mysql-native which is throwing the exception. This was a "Server out of order" exception. Long story short, I found the bug in mysql-native and fixed it [1]. Anyone using mysql-native and vibe-d should update (once code.dlang.org gets around to refreshing it) to 3.0.1. Otherwise, you might get spurious out of order packet exceptions. -Steve [1] https://github.com/mysql-d/mysql-native/pull/226
Re: Deriving a D-class from a CPP-class
On Wednesday, 28 April 2021 at 19:46:00 UTC, Alain De Vos wrote:
Following code produces a linker error.
d: error: undefined symbol: wxApp::OnInit()
```
extern(C++)
{class wxApp {
public:
bool OnInit();
//virtual bool Oninit();
you mean `abstract` for that one?
alias OnInit=wxApp.OnInit;
idk what you intend to do with this, this pattern is for merging
overloads not overriding
bool OnInit(){return true;};
and you might want `override` there
Re: Deriving a D-class from a CPP-class
Following code produces a linker error.
d: error: undefined symbol: wxApp::OnInit()
```
extern(C++)
{class wxApp {
public:
bool OnInit();
//virtual bool Oninit();
}
}
class MYAPP: wxApp {
alias OnInit=wxApp.OnInit;
bool OnInit(){return true;};
}
int main(){
return 0;
}
```
It is rather clear what I want to achieve but virtual functions
give me headache because dlang does not now the word virtual.
Re: Deriving a D-class from a CPP-class
PS: I managed to link to phobo's/runtime & wxgtk at the same time. It goes like this [So someone does not need to re-invent the weel] ``` ldc2 - c test.d c++ test.o -o test -L/usr/local/lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lexecinfo -lpthread -lm -m64 `wxgtk3u-3.0-config --cxxflags --libs` ```
Re: (Maybe) Strange Behaviour of Field Initialization
On Wednesday, 28 April 2021 at 15:35:57 UTC, Adam D. Ruppe wrote:
On Wednesday, 28 April 2021 at 15:09:36 UTC, eXodiquas wrote:
```d
class Particle : Drawable
{
CircleShape shape = new CircleShape(5);
This `new` is actually run at compile time, so every instance
of Particle refers to the same instance of CircleShape (unless
you rebind it).
this.shape.position = Vector2f(x, y);
this.shape.fillColor = Color.Green;
Which means each constructor here overwrites the fields on the
same object!
What you probably want is to construct the shape in the
constructor too, since that is run for each instance created,
instead of just once at compile time and reused for each
instance.
This behavior D has is pretty useful... but also pretty
surprising to people coming from other languages. I kinda wish
the compiler made you be a little more explicit that you
actually did intend to compile time construct it.
The last time I wrote something in D is a few months back, but
I cannot remember this behavior. In the code above `shape`
acts like as if it were `static` without being `static`,
obviously.
Well, the instance is static, but the handle is not.
If you were to do a `this.shape = new Shape;` then that object
would refer to a new one, but if you don't it all uses the same
object.
The code you have is kinda like if you wrote:
static Shape global_shape = (at ctfe) new Shape;
(in the instance) Shape shape = global_shape;
Thanks, this is a pretty good explanation. I get it now. :)
This behavior sounds pretty neat, as long as you know about it. :P
Deriving a D-class from a CPP-class
Is it ok to do the following ?
I.e. derive a D-class from a CPP-class.
The compiler did not complained, and it was OK for him.
```
c++ -c MyClass.cpp
ldc2 main.d MyClass.o -L-lstdc++
```
```
extern(C++){
class MyClass {
public:
int num=1;
void myMethod();
};
};
class Derived : MyClass{
};
int main(){
Derived myObj;
myObj.myMethod();
return 0;
}
```
Could I use this method for using the C++-WXWIDGETS library
directly?
Re: (Maybe) Strange Behaviour of Field Initialization
On Wednesday, 28 April 2021 at 15:09:36 UTC, eXodiquas wrote:
```d
class Particle : Drawable
{
CircleShape shape = new CircleShape(5);
This `new` is actually run at compile time, so every instance of
Particle refers to the same instance of CircleShape (unless you
rebind it).
this.shape.position = Vector2f(x, y);
this.shape.fillColor = Color.Green;
Which means each constructor here overwrites the fields on the
same object!
What you probably want is to construct the shape in the
constructor too, since that is run for each instance created,
instead of just once at compile time and reused for each instance.
This behavior D has is pretty useful... but also pretty
surprising to people coming from other languages. I kinda wish
the compiler made you be a little more explicit that you actually
did intend to compile time construct it.
The last time I wrote something in D is a few months back, but
I cannot remember this behavior. In the code above `shape` acts
like as if it were `static` without being `static`, obviously.
Well, the instance is static, but the handle is not.
If you were to do a `this.shape = new Shape;` then that object
would refer to a new one, but if you don't it all uses the same
object.
The code you have is kinda like if you wrote:
static Shape global_shape = (at ctfe) new Shape;
(in the instance) Shape shape = global_shape;
(Maybe) Strange Behaviour of Field Initialization
Hello everyone,
I am playing around with DSFML and drawing some stuff on the
screen. It works like a charm but I got some unexpected behavior
when building a `Particle` class.
My class looks like this:
```d
class Particle : Drawable
{
CircleShape shape = new CircleShape(5);
this(int x, int y)
{
this.shape.position = Vector2f(x, y);
this.shape.fillColor = Color.Green;
}
void draw(RenderTarget renderTarget, RenderStates renderStates)
{
renderTarget.draw(this.shape);
}
}
```
When I create an array of `Particle`s and try to draw them, all
of them are drawn on the exact same location in my window.
However, when I assign `shape` in the constructor with
`this.shape = new CircleShape(5);` it works as expected.
The last time I wrote something in D is a few months back, but I
cannot remember this behavior. In the code above `shape` acts
like as if it were `static` without being `static`, obviously. Is
there something wrong with D in this case, or is there something
wrong with DSFML or am I just stupid right now and not able to
see the obvious.
Thanks in advance.
Re: Visual D showing weird errors
On Wednesday, 28 April 2021 at 06:06:47 UTC, Rainer Schuetze wrote: On 26/04/2021 20:22, Imperatorn wrote: On Monday, 26 April 2021 at 17:37:26 UTC, Rainer Schuetze wrote: On 26/04/2021 10:00, Raimondo Mancino wrote: [...] The problem is that the semantic engine used by Visual D is working with the DMD frontend of 2.095, but "noreturn" is a new language feature introduced with 2.096. You can filter out messages from "Intellisense" in the Error List window by selecting to show "Build only". I hope I can supply a new version of Visual D with an updated semantic engine soon. That would be awesome There is a new version 1.1.1 available now with the semantic engine updated to dmd 2.096.1. Splendid, thanks! Will try it out soon
Re: Visual D showing weird errors
On 26/04/2021 20:22, Imperatorn wrote: > On Monday, 26 April 2021 at 17:37:26 UTC, Rainer Schuetze wrote: >> >> On 26/04/2021 10:00, Raimondo Mancino wrote: >>> [...] >> >> The problem is that the semantic engine used by Visual D is working >> with the DMD frontend of 2.095, but "noreturn" is a new language >> feature introduced with 2.096. >> >> You can filter out messages from "Intellisense" in the Error List >> window by selecting to show "Build only". >> >> I hope I can supply a new version of Visual D with an updated semantic >> engine soon. > > That would be awesome There is a new version 1.1.1 available now with the semantic engine updated to dmd 2.096.1.
