Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Monday, 14 November 2022 at 20:37:12 UTC, kdevel wrote: On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote: Just came here to say I hit the same bug, here's my import list: * https://issues.dlang.org/show_bug.cgi?id=19937 object._d_assert_fail linker error if compiling with -checkaction=context * https://issues.dlang.org/show_bug.cgi?id=22374 [REG 2.093] 'import std;' with -checkaction=context causes link error * https://issues.dlang.org/show_bug.cgi?id=22902 dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error Does `dmd -allinst ...` help in your case? Hey, it does actually, thanks a bunch!
Can I start a process 'std.process.spawnProcess' with a different process group id other than the parent id?
Doing my research, the only option I see is by using 'setpgid' from 'core.sys.posix.unistd' and setting the foreground process using 'tcsetpgrp' from the same module, but I don't know how to go about doing that with the 'std.process.spawnProcess', I'm writing a shell and the purpose of this is to only kill the child process in case of the SIGINT signal. https://github.com/MKamelll/pat
Re: Need Advice: Union or Variant?
On Thu, Nov 17, 2022 at 10:16:04PM +, jwatson-CO-edu via
Digitalmars-d-learn wrote:
> On Thursday, 17 November 2022 at 21:05:43 UTC, H. S. Teoh wrote:
[...]
> > struct Atom {
> > F_Type kind;
> > union { // anonymous union
> > Atom* car; // - Left `Atom` Pointer
> > Atom* cdr; // - Right `Atom` Pointer
> > double num; // - Number value
> > string str; // - String value,
> > D-string underlies
> > boolbul; // - Boolean value
> > F_Error err = F_Error.NOVALUE; // Error code
> > }
> > }
[...]
> Thank you! This seems nice except there are a few fields that need to
> coexist.
> I need {`car`, `cdr`} -or- {`num`} -or- {`str`} -or- {`bul`}.
> `err` will be outside the union as well because I have decided that
> any type can have an error code attached. As in an error number
> (other than NaN) can be returned instead of reserving certain numbers
> to represent errors. Imagine if there was NaN for every datatype.
[...]
Just create a nested anonymous struct, like this:
struct Atom {
F_Type kind;
union { // anonymous union
struct {
Atom* car; // - Left `Atom`
Pointer
Atom* cdr; // - Right `Atom`
Pointer
}
struct {
double num; // - Number value
string str; // - String value,
D-string underlies
}
boolbul; // - Boolean value
}
F_Error err = F_Error.NOVALUE; // Error code
}
T
--
Meat: euphemism for dead animal. -- Flora
Re: Need Advice: Union or Variant?
On Thursday, 17 November 2022 at 21:19:56 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 17 November 2022 at 20:54:46 UTC, jwatson-CO-edu
wrote:
I have an implementation of the "[Little
Scheme](https://mitpress.mit.edu/9780262560993/the-little-schemer/)" educational programming language written in D, [here](https://github.com/jwatson-CO-edu/SPARROW)".
It has many problems, but the one I want to solve first is the
size of the "atoms" (units of data).
`Atom` is a struct that has fields for every possible type of
data that the language supports. This means that a bool `Atom`
unnecessarily takes up space in memory with fields for number,
string, structure, etc.
[...]
Do I use unions or variants?**
In general, I recommend
[`std.sumtype`](https://dlang.org/phobos/std_sumtype), as it is
one of the best D libraries for this purpose. It is implemented
as a struct containing two fields: the `kind` and a `union` of
all the possible types.
That said, one difficulty you are likely to face is with
refactoring your code to use the
[`match`](https://dlang.org/phobos/std_sumtype#.match) and
[`tryMatch`](https://dlang.org/phobos/std_sumtype#.tryMatch)
functions, as `std.sumtype.SumType` does not expose the
underlying kind field.
Other notable alternatives are:
* [`mir-core`](https://code.dlang.org/packages/mir-core)'s
`mir.algebraic`: http://mir-core.libmir.org/mir_algebraic.html
*
[`taggedalgebraic`](https://code.dlang.org/packages/taggedalgebraic): https://vibed.org/api/taggedalgebraic.taggedalgebraic/
Thank you! This is intriguing.
The different flavors of `Atom` I need will have either {`car`,
`cdr`} -or- {`num`} -or- {`str`} -or- {`bul`}. Does SumType
allow me to store the multiple fields {`car`, `cdr`} in one of
the types, while the other types have only one field?
Since this is a dynamically-typed language, I need the atoms to
both be interchangeable and to serve different purposes at the
same time.
Re: Need Advice: Union or Variant?
On Thursday, 17 November 2022 at 21:05:43 UTC, H. S. Teoh wrote:
Question:
**Where do I begin my consolidation of space within `Atom`?
Do I use
unions or variants?**
In this case, since you're already keeping track of what type
of data is being stored in an Atom, use a union:
struct Atom {
F_Type kind;
union { // anonymous union
Atom* car; // - Left `Atom` Pointer
Atom* cdr; // - Right `Atom` Pointer
double num; // - Number value
string str; // - String value, D-string
underlies
boolbul; // - Boolean value
F_Error err = F_Error.NOVALUE; // Error code
}
}
Use Variant if you don't want to keep track of the type
yourself.
T
Thank you! This seems nice except there are a few fields that
need to coexist.
I need {`car`, `cdr`} -or- {`num`} -or- {`str`} -or- {`bul`}.
`err` will be outside the union as well because I have decided
that any type can have an error code attached. As in an error
number (other than NaN) can be returned instead of reserving
certain numbers to represent errors. Imagine if there was NaN
for every datatype.
"Little Scheme" and PL Design (Code Critique?)
I just pushed a D implementation of "[Little Scheme](https://mitpress.mit.edu/9780262560993/the-little-schemer/)", which is a limited educational version of [Scheme](https://en.wikipedia.org/wiki/Scheme_(programming_language)), to [GitHub](https://github.com/jwatson-CO-edu/SPARROW). _Here I would like to discuss aspects of programming language design from a novice's perspective, including D-specific aspects, rather than try to get forum members to comb through 1500 lines of code._ **Problems / Topics**: * Whenever I create an [`Atom`](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L66) (unit of data), I throw it on the heap and never bother to delete it. I understand that D does GC for me. I am interested in using either [timed GC](https://wiki.dlang.org/Memory_Management#Smooth_Operation) or a [free list](https://wiki.dlang.org/Memory_Management#Free_Lists) for finer control of GC. Which is best for the application, do you think? * Compatibility with both Windows and Linux. What do I need to consider? - Can I create threads/processes under Windows? * PL Authors: Please share what you wish you knew when staring your programming/scripting language. * I am open to questions/critiques. **Components**: 1. [Data](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L43) 1. [Math and Inequality Primitives](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L231) 1. [Lists and Structures](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L348) 1. [Lexer](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L443) 1. [Parser](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L630) 1. [Environment / Variables](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L443) 1. [Primitive Functions](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L630) 1. [Control Flow](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L1006) 1. [Evaluator](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L1127) 1. [REPL](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L1462) **Notes**: * The repo is called SPARROW because I want to transform Little Scheme into my own language through small changes as a way to teach myself PL design. * SPARROW is not a topic of research. I do not have an application in mind other than learning as a side hobby.
Re: Need Advice: Union or Variant?
On Thursday, 17 November 2022 at 20:54:46 UTC, jwatson-CO-edu
wrote:
I have an implementation of the "[Little
Scheme](https://mitpress.mit.edu/9780262560993/the-little-schemer/)" educational programming language written in D, [here](https://github.com/jwatson-CO-edu/SPARROW)".
It has many problems, but the one I want to solve first is the
size of the "atoms" (units of data).
`Atom` is a struct that has fields for every possible type of
data that the language supports. This means that a bool `Atom`
unnecessarily takes up space in memory with fields for number,
string, structure, etc.
Here is the
[definition](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L55):
```d
enum F_Type{
CONS, // Cons pair
STRN, // String/Symbol
NMBR, // Number
EROR, // Error object
BOOL, // Boolean value
FUNC, // Function
}
struct Atom{
F_Type kind; // What kind of atom this is
Atom* car; // - Left `Atom` Pointer
Atom* cdr; // - Right `Atom` Pointer
double num; // - Number value
string str; // - String value, D-string
underlies
boolbul; // - Boolean value
F_Error err = F_Error.NOVALUE; // Error code
}
```
Question:
**Where do I begin my consolidation of space within `Atom`? Do
I use unions or variants?**
In general, I recommend
[`std.sumtype`](https://dlang.org/phobos/std_sumtype), as it is
one of the best D libraries for this purpose. It is implemented
as a struct containing two fields: the `kind` and a `union` of
all the possible types.
That said, one difficulty you are likely to face is with
refactoring your code to use the
[`match`](https://dlang.org/phobos/std_sumtype#.match) and
[`tryMatch`](https://dlang.org/phobos/std_sumtype#.tryMatch)
functions, as `std.sumtype.SumType` does not expose the
underlying kind field.
Other notable alternatives are:
* [`mir-core`](https://code.dlang.org/packages/mir-core)'s
`mir.algebraic`: http://mir-core.libmir.org/mir_algebraic.html
*
[`taggedalgebraic`](https://code.dlang.org/packages/taggedalgebraic): https://vibed.org/api/taggedalgebraic.taggedalgebraic/
Re: Need Advice: Union or Variant?
On Thu, Nov 17, 2022 at 08:54:46PM +, jwatson-CO-edu via
Digitalmars-d-learn wrote:
[...]
> ```d
> enum F_Type{
> CONS, // Cons pair
> STRN, // String/Symbol
> NMBR, // Number
> EROR, // Error object
> BOOL, // Boolean value
> FUNC, // Function
> }
>
> struct Atom{
> F_Type kind; // What kind of atom this is
> Atom* car; // - Left `Atom` Pointer
> Atom* cdr; // - Right `Atom` Pointer
> double num; // - Number value
> string str; // - String value, D-string underlies
> boolbul; // - Boolean value
> F_Error err = F_Error.NOVALUE; // Error code
> }
>
> ```
> Question:
> **Where do I begin my consolidation of space within `Atom`? Do I use
> unions or variants?**
In this case, since you're already keeping track of what type of data is
being stored in an Atom, use a union:
struct Atom {
F_Type kind;
union { // anonymous union
Atom* car; // - Left `Atom` Pointer
Atom* cdr; // - Right `Atom` Pointer
double num; // - Number value
string str; // - String value,
D-string underlies
boolbul; // - Boolean value
F_Error err = F_Error.NOVALUE; // Error code
}
}
Use Variant if you don't want to keep track of the type yourself.
T
--
An elephant: A mouse built to government specifications. -- Robert Heinlein
Need Advice: Union or Variant?
I have an implementation of the "[Little
Scheme](https://mitpress.mit.edu/9780262560993/the-little-schemer/)" educational programming language written in D, [here](https://github.com/jwatson-CO-edu/SPARROW)".
It has many problems, but the one I want to solve first is the
size of the "atoms" (units of data).
`Atom` is a struct that has fields for every possible type of
data that the language supports. This means that a bool `Atom`
unnecessarily takes up space in memory with fields for number,
string, structure, etc.
Here is the
[definition](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L55):
```d
enum F_Type{
CONS, // Cons pair
STRN, // String/Symbol
NMBR, // Number
EROR, // Error object
BOOL, // Boolean value
FUNC, // Function
}
struct Atom{
F_Type kind; // What kind of atom this is
Atom* car; // - Left `Atom` Pointer
Atom* cdr; // - Right `Atom` Pointer
double num; // - Number value
string str; // - String value, D-string
underlies
boolbul; // - Boolean value
F_Error err = F_Error.NOVALUE; // Error code
}
```
Question:
**Where do I begin my consolidation of space within `Atom`? Do I
use unions or variants?**
Re: How do you return a subclass instance from a base class method?
On 11/16/22 11:25 PM, Daniel Donnelly wrote:
I have SubclassOf derived from PosetRelation. For any poset relation,
the transitivity law applies, however, I'd like to return the correct type:
```
PosetRelation transitivity(PosetRelation R, PosetRelation S)
{
if (R.op == S.op)
{
if (R.right is S.left)
return new SubclassOf(R.left, S.right);
}
return null;
}
```
How does one accomplish this in D? Because PosetRelation doesn't know
about SubclassOf, in general.
I'd use a template:
```d
T transitivity(T : PosetRelation)(T R, T S)
{
if (R.op == S.op)
{
if (R.right is S.left)
return new T(R.left, S.right);
}
return null;
}
```
-Steve
Re: How do you return a subclass instance from a base class method?
On Thursday, 17 November 2022 at 06:48:13 UTC, Daniel Donnelly, Jr. wrote: On Thursday, 17 November 2022 at 05:21:05 UTC, MorteFeuille123 wrote: On Thursday, 17 November 2022 at 04:25:13 UTC, Daniel Donnelly, Jr. wrote: [...] You can use TypeInfoClass: [...] I don't get it - you never made use of b1 or b2... yeah this was oversimplified on purpose, I did not realize that this coulmd be confusing. I dont know what you do with your constructor parameter either, would I say, as a second explanation.
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear wrote: I am debating whether or not I should add getter methods to these properties. On one hand, it will inflate the codebase by a lot, on the other hand -- in other languages like Java it is a good practice D has far less need for getters/setters than Java or C++. The reason is [Uniform Function Call Syntax](https://ddili.org/ders/d.en/ufcs.html). This means that a member of a `struct` or `class` can start out as a normal field and be later converted to getter/setter if needed, without breaking calling code. You still might want to use setters when you want to be extra conservative (client code taking address of a struct field will still break if your getter replacing it can't return by `ref`), but for the vast majority of purposes that is an overkill IMO.
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear wrote: ... It's not a lot of code that has been added but if you have a class with say 10 different fields, adding getter methods would definitely increase the code size by a lot, so what are you guys thoughts on this? Food for thought: https://yewtu.be/watch?v=_xLgr6Ng4qQ or https://www.youtube.com/embed/_xLgr6Ng4qQ Matheus.
Re: Is defining get/set methods for every field overkill?
(and will never need) that controlled access. Thanks. BTW the code is not Java, it is 100% D.
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear
wrote:
I am creating a TUI library and I have a class with the
following constant fields:
```
class Label : Renderable {
const string text;
const TextAlignment textAlignment;
const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color)
{
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
I am debating whether or not I should add getter methods to
these properties. On one hand, it will inflate the codebase by
a lot, on the other hand -- in other languages like Java it is
a good practice:
```
class Label : Renderable {
private const string text;
private const TextAlignment textAlignment;
private const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color)
{
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
string getText() const {
return text;
}
TextAlignment getTextAlignment() const {
return textAlignment;
}
Color getColor() const {
return color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
It's not a lot of code that has been added but if you have a
class with say 10 different fields, adding getter methods would
definitely increase the code size by a lot, so what are you
guys thoughts on this?
The Java code you presented requires getter, since your member
variables are private (which is the default in java anyway). In
D, public is the default.
First decided whether you really do want them public (because
those members now form a part of the interface that you present
to the user of that class, which immediately constrains you in
terms of changes).
Decide whether they are in fact amenable to direct public access
(i.e. do you need to test for null, or have some other rule that
you must meet before providing a value back to the caller?
Better to just make them private, and then provide getters. Then
if you do need to implement a check for null or whatever, then
you can do that with changing the interface.
Controlled access to data (i.e. data protection) should always be
the default, unless you are absolutely sure you don't need (and
will never need) that controlled access.
