Re: iz v0.6.18 - Now with a modern, fast, @safe, getopt-like function
On Monday, 28 May 2018 at 00:53:45 UTC, Basile B. wrote: Last time i promoted my stuff here there were two compiler/Phobos bugs preventing to activate this nice getopt-like function. specs: - It's based on UDA. - It supports multiple locations for UDA-fied functions and variables. - It doesn't use pointers, UDA-ified variable are accessed without intermediary. - It's faster than the phobos one (although getopt is never a bottleneck) - It's `@safe` and can be even `nothrow` It could be easily added to phobos (just need to convert some EnumSet to BitFlag). - code: https://github.com/BBasile/iz/blob/master/import/iz/options.d#L596 - DUB: https://code.dlang.org/packages/iz - doc: https://iz.dpldocs.info/v0.6.18/iz.options.handleArguments.html - cool demo: https://github.com/BBasile/Coedit/blob/master/dastworx/src/main.d#L18 Note that despite of the run-time compatibility mention in the README, this module is part of a subset of IZ that can be used without all the concept of Nogc as used in iz. (at some point i should split the twos parts). such attribute-based getopt is now used in styx driver e.g - [here](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/session.sx?ref_type=heads#L107) - [here](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/session.sx?ref_type=heads#L492) In styx now I just do ``` if !getOpt, ) do return 1; ``` At some point we forgot what we wanted to do in D ;)
Re: Beta 2.104.0
On Tuesday, 2 May 2023 at 08:47:35 UTC, Iain Buclaw wrote: On Tuesday, 2 May 2023 at 03:08:00 UTC, zjh wrote: On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. [104](https://dlang.org/changelog/2.104.0.html) ```d alias Tint = int; @Tint void f(); ``` Here says not to use basic types as attributes, but the following example give it another basic type? ```d @int void f(); ``` The keyword here in the changelog is: **would**; that is to say, the compiler previously rejected basic types, but now they are accepted. It was already allowed to put types in UDAs, but the parser would reject basic types written directly, requiring the use of an alias. I'll have a think about how that entry could be rephrased to avoid confusion, though you are welcome to raise your own pull request to clarify the wording. That's a half baked change, it would have been better to go a bit further: previously ```d alias Tint = int; @Tint void f(); ``` now ```d @int void f(); ``` nice. But previously ```d alias Tint = int; @Tint(1) void f(); ``` now ```d @int(1) void f(); // Not Good ``` that's unfortunately still an error.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote: This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times. It's a misconception of the problem that the DIP tried to solve. What the DIP tried to solve is that the compiler should know that you are using an enum member. Actually I even think this should work without any special syntax, as a "last resort", let's say. But as you've explained, through Mike's report, this causes problems for D because the identifier resolution is tied to a particular implementation, i.e your fast symtabs.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] While I was rather "pro" I think that D lacked an absolute necessity for that. As explained earlier on IRC, enum type inference is also very intersting when the language has a bitfield type based on an enum, like the `Set Of` pascal construct, which makes enum member something really commonly used, much more than in D.
Dexed-ide 3.9.18
This update allows to open makefiles as language-agnostic projects. For example The sortcut for "Compile project" will have the same effect as make -f Not very interesting for D one would say, however as this feature is useful for another of my project that addition gives strong guarantees that dexed will not be abandoned. Otherwise the release comes with a few fixes: - The lack of maintenance of dparse lead to use a derived Parser class to fix crashes that can happen with incomplete code. - Projects groups and workspace persistence was broken - Packagers wont have to deal with my old, unmaintained "iz" D library. Links: - [release](https://gitlab.com/basile.b/dexed/-/releases) - [homepage](https://gitlab.com/basile.b/dexed)
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 16:12:25 UTC, Iain Buclaw wrote: On Tuesday, 15 February 2022 at 13:27:18 UTC, Basile B. wrote: On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list Maybe an issue could be raised against the [dlang-bot](https://github.com/dlang/dlang-bot) to request better handling of ambiguous commit messages? Yes but in the meantime I find strange that you have just approved a PR that will have the same effect [with issue 2]. [with issue 2]: https://github.com/dlang/dmd/pull/13663
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list
Re: styx, a programming languange written in D, is on the bootstrap path
On Sunday, 16 January 2022 at 18:53:45 UTC, Brian Callahan wrote: I was able to make a quick port to OpenBSD; works fine there too. Thanks for your work on this! ~Brian holly s**t ! I'm a bit surprised that it works, especially because of the way linking is done.
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 18:03:12 UTC, IGotD- wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Interesting project. A few questions. I see that you use "var auto name" in order to automatically infer the type. Would it be possible just using "var name" for that, similar to other popular languages. There is currently no information about memory management, is this something you have an idea how to design right now? It has a memory management system very comparable to older Delphi (<= 2007) or current FreePascal. So dynamic arrays are reference counted and automatically managed when used a local var. Classes and structures are manually managed but the dtor is automatically called when the instance is a local. This system is proven to work as the compiler itself is now rewritten in styx. (example, the valgrind report after running the compiler with the equivalent of D "-unittest" CLI option : https://gitlab.com/styx-lang/styx/-/jobs/1980055910#L110. To be honest I already knew it will work before implementing ref counting. This has been used for something like 30 years by hundreds and hundreds of programmers.
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. Interesting project! How did you move from D to Styx? (I assume bootstrapping means a self hosting compiler?) Did you write some scripts to translate? It turns out that finally everything was translated manually. This was a bit painful but also an opportunity to review older parts and to change a details that otherwise would not have been done.
Re: Gordon programming language
On Sunday, 24 October 2021 at 10:13:14 UTC, Tero Hänninen wrote: Hello, decided I'd post about my primarily D-influenced programming language here. Nice work. It's data oriented, compact and despite D's influence, has a very different personality with no emphasis on metaprogramming – albeit having simple polymorphism and even compile time execution. Stability is something I care about deeply so you can expect few to no deprecations over time after some initial instability perhaps. Feature set is not large and I'm not willing to add a whole lot of "cool" convenience features besides what there already is, and there is no support for either OO or functional style programming. However, I'm rather open to adding features that unlock great performance benefits, such as intrinsics support. Support for LLVM intrinsics should be indeed of a great value added. That could work by adding a new attribute with a string exp to recognize it. without that the oprations that are done in the FPU can only be based on assembly and less inlinable. The module system is similar to Rust and works nicely with conditional compilation in that you can exclude entire modules and directories and, unlike in Rust, use conditional symbols that are automatically visible to all submodules. The compiler frontend is about 34k lines of code, self hosting and very fast. LLVM is the backend, but with the MIR used in the compiler, it's fairly straight forward to bolt on other backends. Congrats for reaching self-hosting. Once thing I notice is that there does not seem to be a way to generate debug info. You really should support them (LLVM C api has a whole header with everything you need to achieve that), because not only this allows to debug the compiler more easily but also can be used to easily instrument code in a generic way. With debug info, you can of course debug but also profile (valgrind --tool=calgrind), find leaks (valgrind), cover (kcov), etc. Compiler source code: https://github.com/tjhann/gordon Website: https://tjhann.github.io/gordon-web/ I don't know how to make websites... and I want a much lighter background actually. Take a look! :)
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: [...] - [assets](https://gitlab.com/basile.b/dexed/-/releases). Note that the automated Windows build is still broken. Windows assets are now live [here](https://ci.appveyor.com/project/BBasile/dexed/builds/41098624/artifacts).
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 09:52:14 UTC, Basile B. wrote: On Monday, 11 October 2021 at 07:42:12 UTC, Imperatorn wrote: On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: ## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. [...] I'm on Windows though, but thanks for maintaining dexed it's easy to build. If a script can do it on appveyor, a human can do it on its windows box. Actually if the appveyor build fails it's because of d-scanner, not dexed. mmmh lmao actually. The build fails because the checkout is done before entering the repo dir: https://gitlab.com/basile.b/dexed/-/blob/master/.appveyor.yml#L52
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 07:42:12 UTC, Imperatorn wrote: On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: ## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. [...] I'm on Windows though, but thanks for maintaining dexed it's easy to build. If a script can do it on appveyor, a human can do it on its windows box. Actually if the appveyor build fails it's because of d-scanner, not dexed.
dexed-ide v3.9.13
## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. ## Bugs fixed - diff dialog: the content reloaded matched to the state when the dialog was shown, not when closed. (#97) - editor, debugging: during a debugging session, wrong icon displayed when a breakpoint is removed. - DUB project inspector: the tree was empty if the project is moslty organized in subpackages. - DUB projects: version number without the patch component were not accepted. ## links - [homepage](https://gitlab.com/basile.b/dexed) - [assets](https://gitlab.com/basile.b/dexed/-/releases). Note that the automated Windows build is still broken.
Re: Release 2.098.0
On Sunday, 10 October 2021 at 14:10:53 UTC, Martin Nowak wrote: Glad to announce D 2.098.0, ♥ to the 62 contributors. This release comes with template alias assignments, ImportC, a forking parallel GC for POSIX systems, and many more changes. http://dlang.org/download.html http://dlang.org/changelog/2.098.0.html -Martin The most important fix in this version for me is not well exposed in the changelog. With https://github.com/dlang/dmd/pull/12978, finally all inherited fields of a class are displayed, e.g when using `p *instance` in gdb, which painfully missed before (unless you used GDB or LDC of course). Thanks in particular to Rainers for that fix !
Dexe-ide 3.9.12
# v3.9.12 - editor: a new option, _textCompletion_, sets if the completion menu includes the identifiers obtained by word-splitting the whole document. (#85) - editor: prevent completion menu to show on fast enough (< to the _autoDotDelay_ setting) `..`. - Halstead metrics: show full function signatures. - projects: added the _Check semantics_ to the menu. (#83) - DUB projects: added support for the _syntax_ build type. (#83) - GDB commander: arguments of the _Debugee Options_ can be temporarily deactivated by prepending `//`. - GDB commander: add an option allowing to set the path to the gdb binary. (#73) - GDB commander: the context menu of the ASM view allows to resume execution until the selected instruction. (#71) - Search results: use GNU style messages. (#84) ## Regressions fixed - editor, _closeCompletionCharsWithSpace_ broken by [git b65bb860](https://gitlab.com/basile.b/dexed/-/commit/b65bb860e45c47e3c48bf513aeafd9968daa2482). ## Bugs fixed - D2 highlighter: for `Call()`, `Call` wont be considered anymore as a type. (#69) - GDB commander: 5 empty arguments were passed to the main function called by libc. (#86) - Symlist: errors were not visible enough since moved to the top. (#92) ## Other - can be build with Lazarus 2.2 but backward compatible 2.0.z. - provided binaries are build with Lazarus 2.0.12 due to 2.2 not being released. --- To get a release [see here](https://gitlab.com/basile.b/dexed/-/releases). Note that the appveyor build has failed this time so no offical windows binaries.
Re: Bugzilla Reward System
On Thursday, 16 September 2021 at 11:56:21 UTC, Mike Parker wrote: In my summary of last month's D Language Foundation meeting, I mentioned that we discussed a system intended to reward contributors who contribute pull requests that fix Bugzilla issues. This was Razvan Nitu's baby from conception to implementation, and we all think it is a great idea. The system has been running in the background for a few weeks now, quietly gathering data and awarding points, proving that the programming side works as intended. Our first round of point scoring kicks off on September 20th. Razvan has put together a blog post explaining how the system works. We'll revise and adapt the system as needed as time goes by. In the meantime, happy bug fixing! The blog: https://dlang.org/blog/2021/09/16/bugzilla-reward-system/ Reddit: https://www.reddit.com/r/d_language/comments/ppbp7d/bugzilla_reward_system/ This is a good move, I hope it will work so that D will keep contributors that are not already gone and gain new talented ones. Another answer mentions that the lack of "issue triage" might cause problems. I think to the opposite that this system could encourage 1. better triage 2. better reviews But well, we'll see if this works next year. Let's not be negative ;)
Re: Beta 2.097.0
On Thursday, 13 May 2021 at 15:26:59 UTC, Berni44 wrote: On Thursday, 13 May 2021 at 13:38:44 UTC, jmh530 wrote: "11. Floating point numbers don't allocate with the GC anymore." Should this be "11. Formatting floating point numbers doesn't allocate with the GC anymore." Probably my fault. Is it possible to still change this? What do I have to do? Just edit this file : https://github.com/dlang/phobos/blob/master/changelog/formatting_floats_nogc.dd and you're good.
Re: styx, a programming languange written in D, is on the bootstrap path
On Tuesday, 19 January 2021 at 12:50:40 UTC, Max Haughton wrote: On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: [...] self-hosting is not started yet, maybe next month, classes are still to be implemented. I plan to use dparse for the most part, not only to convert but also to detect non bootstrapable code or missing features. Then, feature freeze, convert, catch and fix bugs as they will appear when feading the compiler with real food. [...] Thoughts on libfirm? I am thinking about writing an online book about compiler backends so I'm curious what it's like to work with. There is this small wiki page https://proglangdesign.net/wiki/firm written by myself, so I have not much to add, as I've dropped FIRM at the very beginning of the backend exprimentation.
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 18:03:12 UTC, IGotD- wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Interesting project. A few questions. I see that you use "var auto name" in order to automatically infer the type. Would it be possible just using "var name" for that, similar to other popular languages. There is currently no information about memory management, is this something you have an idea how to design right now? yes, it would be possible, but it wont be done. In Styx "auto" is a type joker and that's it.
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 17:51:16 UTC, Basile B. wrote: On Monday, 18 January 2021 at 17:45:16 UTC, Basile B. wrote: On Friday, 15 January 2021 at 19:40:11 UTC, Ola Fosheim Grøstad wrote: [...] Yeah, in addition to my real name, I've been invovled in dmd as "Nils Lankila" and "Stian Gulpen" which are names generated using specialized services. You can choose to have a swedish name for example. on the internet nobody knows you're a dog ;) https://de.fakenamegenerator.com/
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 17:45:16 UTC, Basile B. wrote: On Friday, 15 January 2021 at 19:40:11 UTC, Ola Fosheim Grøstad wrote: [...] Yeah, in addition to my real name, I've been invovled in dmd as "Nils Lankila" and "Stian Gulpen" which are names generated using specialized services. You can choose to have a swedish name for example. on the internet nobody knows you're a dog ;)
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 19:40:11 UTC, Ola Fosheim Grøstad wrote: On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: I plan to use dparse for the most part, not only to convert but also to detect non bootstrapable code or missing features. Ah, smart. I've been thinking about using an existing d-parser to convert unit tests from D to my Dex syntax (experimental project). Modifying the compiler is fun, but writing unit tests is not... This is a noble reason. Styx has no such motivations. It is simpler than D1 for example and has no killer feature, What made D1 attractive to many C++ programmers was that it was stripped down. Also, many language designers get tempted to add many features that are hollow, then they regret it and rip it all out again (lots of wasted effort and source code). So, being very restrictive and patient is a good thing, I believe. The truly good ideas takes time to "grow" (in ones mind). just 3 or 4 creative things are - optional break/continue expression - explicit overloads - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) - pointers to member function is very different from what I have seen so far (no fat pointer) "Nils" is a very scandinavian name? :-) Yeah, in addition to my real name, I've been invovled in dmd as "Nils Lankila" and "Stian Gulpen" which are names generated using specialized services. You can choose to have a swedish name for example.
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 19:25:38 UTC, Per Nordlöw wrote: On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) Can you give examples of what a DotExpression alias is? They allow to pull heavily nested members, similarly as getters are sometime used and are supposed to make object composition easier. This [1] is the test file used to develop the feature. [1] https://gitlab.com/styx-lang/styx/-/raw/51611f2d5c023c0edfe97968b543660ae2e89c26/tests/backend/dotexp_alias.sx
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. Interesting project! How did you move from D to Styx? (I assume bootstrapping means a self hosting compiler?) Did you write some scripts to translate? self-hosting is not started yet, maybe next month, classes are still to be implemented. I plan to use dparse for the most part, not only to convert but also to detect non bootstrapable code or missing features. Then, feature freeze, convert, catch and fix bugs as they will appear when feading the compiler with real food. I've found myself to sketch new programming languages whenever I hit things in existing languages that I find annoying over the past decade or so. This is a noble reason. Styx has no such motivations. It is simpler than D1 for example and has no killer feature, just 3 or 4 creative things are - optional break/continue expression - explicit overloads - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) - pointers to member function is very different from what I have seen so far (no fat pointer) I finally decided to start on a lexer for it... How long did it take you to get where you are now? The project exists since several years (2017-04-13 20:05:51) but is only actively developed since july 2020. The game changers were: - to use LLVM instead of libfirm - to that some part of the initial design were bad - proper lvalue implementation
Re: styx, a programming languange written in D, is on the bootstrap path
On Thursday, 14 January 2021 at 20:21:42 UTC, Daniel N wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Love the design FWIW. Initially I wanted something like libdparse + dsymbol, i.e a clean split of the AST the semantic phase, semi-success. There's still a Symbol class but the types have been moved to the AST. Another design idea is that I wanted to have useful visitors, i.e that always process a whole compilation unit, but that did not work well so now visitors are pretty much state-less and when a "state" is required it is stored in scopes, "like in dmd". I quote that because many times I've discovered that, in dmd, if things are done in a way and not another, it's not arbitrary. The main reason for that is that if you want to support out of order declarations and "auto" you have to drive the semantics like in dmd, declaration -> bodies -> statements -> expressions, and when you reach something that is not known you launch this chain...
styx, a programming languange written in D, is on the bootstrap path
This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 11:55:12 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 6 January 2021 at 11:39:08 UTC, Basile B. wrote: Hmm... My take is that this proposal is auto with a constraint, except it will also do implicit conversion. yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^ Do you disagree? No. I agree. Do you imagine if this conversation was in the offical DIP review. E.g those two a**holes who troll the review process /s
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 11:29:42 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 6 January 2021 at 11:18:22 UTC, Basile B. wrote: I thought about auto when reading the DIP too, but auto is more used like a Type (although being a storage class ;) ). It's never used to infer a value, i.e an expression. While I understand what you mean this is unrelated. Dollar is very well suited. Hmm... My take is that this proposal is auto with a constraint, except it will also do implicit conversion. yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 11:11:41 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim
Grøstad wrote:
int[_] = …
or
_[_] …
To expand on this with more examples, you might want to
constrain "auto" in various ways with pattern matching:
// ensure static array of something with length 4
_[4] v = f();
// ensure that I get a MyContainer with some unspecified type
elements
MyContainer<_> c = g();
// define a function that swaps the content of an array of
length 2
void swap(ref _[2] a){ … }
// it would also be shorter than auto, but not sure if that is
a good thing
_ x = 3 // same as "auto x = 3"
I thought about auto when reading the DIP too, but auto is more
used like a Type (although being a storage class ;) ). It's never
used to infer a value, i.e an expression. While I understand what
you mean this is unrelated. Dollar is very well suited.
Maybe you could create the underscore-lang to showcase the idea ;)
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad wrote: I am in favour of more controlled type inference in general, but perhaps this one is a bit specific. What if you defined "_" to mean "deduce whatever should be in this spot", not only for static arrays, but for all types? Then you could do: int[_] = … or _[_] … etc '$' is not an ident char, that's why that works
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 09:55:34 UTC, Basile B. wrote: On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote: On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote: [...] The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org Before posting a review, I have a question: What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ? (nothing is explained here https://github.com/dlang/dmd/pull/4373) well never mind, I've mentioned in the review that nothing is explaiend about the old attempt.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote: On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote: However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org Before posting a review, I have a question: What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ? (nothing is explained here https://github.com/dlang/dmd/pull/4373)
Re: LDC 1.24.0-beta1
On Monday, 19 October 2020 at 20:49:14 UTC, Andre Pany wrote: On Monday, 19 October 2020 at 18:48:11 UTC, notna wrote: On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: It would be convenient if you provided a .exe installer as well. Not sure what to do with the .7z file without manual tinkering. use scoop for Windows package mgmt in a user context. build with developers in mind. for installation see: https://scoop.sh/ simple as: * scoop install dmd * scoop install ldc stay always up to date: * scoop update * scoop update * ... and MUCH more, see https://github.com/lukesampson/scoop/wiki Also Microsoft is working on a package manager which might be an option in the future https://docs.microsoft.com/de-de/windows/package-manager/ Kind regards Andre Looks a bit like "classic MS". Instead of buying something similar that exists they do their own.
Re: Release D 2.094.0
On Wednesday, 30 September 2020 at 18:38:25 UTC, Basile B. wrote: On Tuesday, 29 September 2020 at 13:38:58 UTC, apz28 wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module. Only the version build during continuous *integration,
Re: Release D 2.094.0
On Tuesday, 29 September 2020 at 13:38:58 UTC, apz28 wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module. Only the version build during continuous have assert on since a few weeks [1]. The PR that should have allowed the same in the official release [2] has been closed by error, hence the changelog lead to a wrong idea about the current state of assert in the compiler itself. [1] https://github.com/dlang/dmd/pull/11523 [2] https://github.com/dlang/dmd/pull/10679
Re: LDC 1.23.0
On Wednesday, 19 August 2020 at 23:47:34 UTC, kinke wrote: On Wednesday, 19 August 2020 at 23:30:30 UTC, Basile B. wrote: gdwarf really ? this is possible ? Not that this is not a great news but you told me once this was not quite possible (https://forum.dlang.org/post/ttblgcwiwmdhyukzp...@forum.dlang.org). I said that LDC/LLVM generate CodeView, but knew that clang can emit it. Shortly after your post, another guy asked for DWARF on Windows, so I did a little bit of digging. I haven't properly tested it (no working gdb/lldb on my Windows box), You can get gdb for windows by installing Lazarus or even more simply try one of the alternative version that they propose [1]. feedback is appreciated. I will test the feature soon, since now I want to see if the GDB GUI of my IDE can be activated or not on windows. [1] https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
Re: LDC 1.23.0
On Wednesday, 19 August 2020 at 17:45:46 UTC, kinke wrote: Glad to announce LDC 1.23 - some highlights: - Based on D 2.093.1+. - LLVM for prebuilt packages bumped to v10.0.1; min version raised to 6.0. - Cross-compiling to the iOS/x86_64 simulator now works out-of-the-box with the prebuilt Mac package. - Windows: New -gdwarf command-line option for debugging with gdb/lldb. - Fix linker errors for -betterC wrt. cleanups (structs with dtor, `scope(exit)`). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.23.0 Thanks to all contributors! gdwarf really ? this is possible ? Not that this is not a great news but you told me once this was not quite possible (https://forum.dlang.org/post/ttblgcwiwmdhyukzp...@forum.dlang.org).
Re: D IDE Dexed - v3.9.0
On Saturday, 9 May 2020 at 11:33:08 UTC, notna wrote: On Friday, 8 May 2020 at 00:46:04 UTC, Basile B. wrote: Sorry, I'm tempted to drop official Windows support good. I have an old win7 DVD but I'd prefer if someone who actually uses Windows could fix this. For now let's talk here https://gitlab.com/basile.b/dexed/-/issues/37, as it is very specific. Thanks... seems like I was the only one interested in using it on Windows, so... most of the time I use VSCodium with the great code-d plugin by now anyhow, so I will survive also without dexed ;) I've fixed it yesterday (https://gitlab.com/basile.b/dexed/-/commit/730c2a4e6e1ae18d603d91c471bf3b6459ce7b52) using my mom's laptop ^^. Fortunately I've found an old post from p0nce (https://forum.dlang.org/post/mscgsclxwtjcferfx...@forum.dlang.org) that explained in detail how to make dll on win and the error has become obvious. IMPORTANT: Use `export` for any call you want exported in your DLL! Also in IDA the list of the exports showed nothing... that was a huge f**ing clue. anyway the Windows version is verified to work now. Only thing is that a msvc140.dll might be necessary, but this is not a dexed problem. In this case people can just get it from the official microsoft website.
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... So I thought maybe I can give it a shot with a youtube channel? I already invent a cool personality - think Dirk Gently in computer science setting;) If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is.. I rarely watch videos about programming (even talk) but I'd certainly take a look if you start something. It cant be worst than one of these tutorial produced by random Indian guys.
Re: D IDE Dexed - v3.9.0
On Thursday, 7 May 2020 at 23:50:51 UTC, notna wrote: On Tuesday, 5 May 2020 at 22:00:30 UTC, Basile B. wrote: Try the default procedure now. i.e using lazbuild as explained in the documentation. As the library is statically linked this is mandatory anyway. pull'ed incl submodules again... re-build everything, DLL is there BUT... - starting dexed.exe in PowerShell doesn't show anything - starting dexed.exe in CMD brings up an error window, saying something like "application couldn't be started, (0xc07b) ..." Sorry, I'm tempted to drop official Windows support good. I have an old win7 DVD but I'd prefer if someone who actually uses Windows could fix this. For now let's talk here https://gitlab.com/basile.b/dexed/-/issues/37, as it is very specific.
Re: D IDE Dexed - v3.9.0
On Tuesday, 5 May 2020 at 20:05:25 UTC, notna wrote: On Tuesday, 5 May 2020 at 20:03:38 UTC, notna wrote: On Tuesday, 5 May 2020 at 12:53:29 UTC, Basile B. wrote: On Win10 64Bit, after compiling as described in https://basile.b.gitlab.io/dexed/build.html, I have a "dexed.exe" but if I run it, I get "couldn't find dexed-d.dll" ... Can you give a try again after pulling latest changes ? Actually the library indicated as missing was build by calling bash which obviously could not work on Windows. I have pushed a change that replaces this by a direct call to dub since the script was essentially used to "cd" and that's not required as dub has "--root" Thanks for your changes. Seems like linking take a bit longer now but the DLL is still not build. The log from DUB tends to say the opposite. The dll should be in "C:\Temp\Git\dexed\bin". Maybe the extension is missing then ? Another change => calling "dexed.exe" doesn't shop the error popup as it did before... grrr... doesn't _SHOW_ the error popup as it did before... Try the default procedure now. i.e using lazbuild as explained in the documentation. As the library is statically linked this is mandatory anyway.
Re: D IDE Dexed - v3.9.0
On Sunday, 3 May 2020 at 18:40:37 UTC, notna wrote: On Saturday, 25 April 2020 at 06:55:19 UTC, Basile B. wrote: Despite of the mini drama last year I've continued developping dexed. The changelog since last announce here is a bit long, check https://gitlab.com/basile.b/dexed/-/releases for more information and get the releases (linux only). On Win10 64Bit, after compiling as described in https://basile.b.gitlab.io/dexed/build.html, I have a "dexed.exe" but if I run it, I get "couldn't find dexed-d.dll" ... Can you give a try again after pulling latest changes ? Actually the library indicated as missing was build by calling bash which obviously could not work on Windows. I have pushed a change that replaces this by a direct call to dub since the script was essentially used to "cd" and that's not required as dub has "--root"
Re: D IDE Dexed - v3.9.0
On Sunday, 3 May 2020 at 18:40:37 UTC, notna wrote: On Saturday, 25 April 2020 at 06:55:19 UTC, Basile B. wrote: Despite of the mini drama last year I've continued developping dexed. The changelog since last announce here is a bit long, check https://gitlab.com/basile.b/dexed/-/releases for more information and get the releases (linux only). On Win10 64Bit, after compiling as described in https://basile.b.gitlab.io/dexed/build.html, I have a "dexed.exe" but if I run it, I get "couldn't find dexed-d.dll" ... It should be in the same folder as dexed.exe. If it's not there this means that the preprocess has failed. You must have ldc2 visible in the PATH variable. For now I can only advice you tobuild libdexed-d.dll manually to see what the problem is. in the repository, sub folder dexed-d, try $ dub.exe --compiler=ldc2 and tells me what's happening. dexed-d.dll should be created in the same folder as dexed.exe. TBH I don't know if Windows is still supported. As a user I have totally dropped this system, since I didn't use it since years but only to build dexed.
Re: DDOC generator Harbored-Mod - v0.3.4
On Saturday, 25 April 2020 at 08:36:40 UTC, 9il wrote: On Saturday, 25 April 2020 at 06:50:07 UTC, Basile B. wrote: [1] https://gitlab.com/basile.b/harbored-mod Note that I don't have access to the DUB registry to update the location so Ilya Y. if you read this maybe you can do that [2] ;). [2] https://code.dlang.org/packages/harbored-mod done thanks Ilya.
D IDE Dexed - v3.9.0
Despite of the mini drama last year I've continued developping dexed. The changelog since last announce here is a bit long, check https://gitlab.com/basile.b/dexed/-/releases for more information and get the releases (linux only).
DDOC generator Harbored-Mod - v0.3.4
Harbored-Mod is a lesser known documentation generator for the D programming language. Since the last release several old bugs have been fixed. The location[1] has changed too. - added support for anchors via anchor.js - enum member attributes are displayed (they didn't exist when the soft was created). - comments for enum members were not displayed. - fix a problem when collapsing the TOC in index.html - the template param for typed and templated enum was not displayed. - empty headers were generated, which has been revealed by the addition of anchors. [1] https://gitlab.com/basile.b/harbored-mod Note that I don't have access to the DUB registry to update the location so Ilya Y. if you read this maybe you can do that [2] ;). [2] https://code.dlang.org/packages/harbored-mod
Re: DIP 1027---String Interpolation---Format Assessment
On Monday, 24 February 2020 at 10:02:26 UTC, Mike Parker wrote: I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all. Not at all. In this case, as the DIP author, Walter could have chosen to revise the DIP with a new implementation. He chose not to. He wasn't persuaded by the arguments in the thread. Yeah, not to mention that in first place I think that he made a DIP for named args because the commuity was unable to formulate a good propostion, while he was himself not "pro-named args"... (maybe, I think i read this in the past)
Re: Bison 3.5 is released, and features a D backend
On Wednesday, 1 January 2020 at 09:47:11 UTC, Akim Demaille wrote: Hi all! GNU Bison 3.5 was released with a D backend (https://savannah.gnu.org/forum/forum.php?forum_id=9639). This backend is functional, and you can get a sense of its current shape by looking at the shipped example (a calculator, what did you expect?): https://github.com/akimd/bison/blob/master/examples/d/calc.y. Bison is an LR parser generator. It supports not only Yacc's original LALR(1) parsers, but also canonical LR and IELR(1) which are strictly more powerful (meaning: they accept wider classes of languages). It also features Generalized LR, which can even parse ambiguous grammars. The D backend currently does not support the full range of Bison features. We desperately need some skilled D programmer(s) to support this backend. It was first contributed by Oliver Mangold, based on Paolo Bonzini's Java backend. It was cleaned and improved thanks to H. S. Teoh, yet it's certainly not yet fitting perfectly the D spirit. Since the backend is still experimental, there is flexibility: it can be changed and improved until it meets the D community standards. If you would like to contribute, please reach out to us via bison-patc...@gnu.org, or help-bi...@gnu.org. Best wishes for 2020. Cheers! nice, thanks
Re: argument parsing into structure
On Wednesday, 26 June 2019 at 23:35:59 UTC, Jesse Phillips wrote: On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote: On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote: On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote: Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around. https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n I have another technique for sub commands I should write about too. http://code.dlang.org/packages/argsd I think we are several having written alternative getopt() systems. I made one too last year, it allows to write tools very nicely. Recent example for a device flasher: The thing is, I didn't write an alternative, mine utilizes getopt which was the point of the article. I could build out new functionality onto a standard API which didn't support it. It isn't as robust as it could be. Sorry budy, I didn't want to ruin your announce. Hold on ;)
Re: argument parsing into structure
On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:
On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips
wrote:
Sometimes a good API isn't the right answer. I like getopt as
it is but I wanted a little different control. So I wrote up
an article on my work around.
https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
I have another technique for sub commands I should write about
too.
http://code.dlang.org/packages/argsd
I think we are several having written alternative getopt()
systems.
I made one too last year, it allows to write tools very nicely.
Recent example for a device flasher:
---
module app;
import
iz.options;
struct Handler
{
private:
public:
/// Handle the "--help" command.
@Argument("--help", "prints the command line usage",
ArgFlags(ArgFlag.allowShort))
static void getHelp();
/// Handle the "--info" command.
@Argument("--info", "prints the list of connected mods",
ArgFlags(ArgFlag.allowShort))
static void getInfo();
/// Handle the "--readFlash" command.
@Argument("--readFlash", "read the firmware from the mod and
save it to the specified file")
static void readFlash(string fname);
/// Handle the "--writeFlash" command.
@Argument("--writeFlash", "read the firmware from the
specified file and send it to the mod")
static void saveFlash(string fname);
/// Handle the "--reset" command.
@Argument("--reset", "reset to factory state",
ArgFlags(ArgFlag.allowShort))
static void reset();
}
void main(string[] args)
{
if (!handleArguments!(CanThrow, Handler)(args[1..$]) ||
args.length == 1)
writeln(help!Handler);
}
---
https://github.com/Basile-z/iz/blob/master/import/iz/options.d#L379
Though I've detected several little flaws since it was written,
but I don't care much anymore about my own stuff these days...
Re: my first kernel in betterC D
On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote: https://github.com/kaleidicforks/mkernel-d I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work. It seems to. I didn't try loading with GRUB. The dub.sdl isn't quite right, so best run ./build.sh Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming. IIRC there used to be a protection supposed to prevent hijacking of package names, e.g someone that would register from a fork before the original package, blocking the original author, considered as more legit. But https://github.com/dlang/dub-registry/pull/425/files seems to say that it should work now.
Re: D IDE dexed - v3.7.10 available
On Thursday, 13 June 2019 at 20:12:41 UTC, Machine Code wrote: On Monday, 10 June 2019 at 20:34:14 UTC, Basile B. wrote: A small update of this IDE dedicated to the D languages and its tools [1]. Only some small fixes and adjustments, see [2] for details and pre-compiled binaries. [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10 You're the author? Thank you very much! When I was working on project on linux, this was the best I could find. It has a issue with crashing but deleting a temporary file (sorry don't remeber name now...) fixed the issue. So you've written this IDE by youtself? I was interesting in building a small IDE. Do you have any books (not sure if exists) on topic? or links/resource that might be helpful? I don't think there's anything on the topic because this is not technical: UX best practices (the way the toolkit is made should enforce that automatically), observer pattern, mediator pattern, processes and standard streams, much serialization too, and you're good.
Re: D IDE dexed - v3.7.10 available
On Tuesday, 11 June 2019 at 21:05:05 UTC, Kaylan Tussey wrote: On Monday, 10 June 2019 at 20:34:14 UTC, Basile B. wrote: A small update of this IDE dedicated to the D languages and its tools [1]. Only some small fixes and adjustments, see [2] for details and pre-compiled binaries. [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10 I tried this ide. Best one aside from vd+vs imo. But it has one problem. It's written in a language i'm not familiar with :(. I can't add any functionality I wanted, such as a really nice directory/file manipulator. I found myself getting down and dirty in windows explorer then directing dexed to the folders/files. Unless I missed something? There's not much to add to the mini explorer anymore but shell actions (rename, delete, etc.). It looks easy at first glance but a naive implementation will not allow to undo/redo from the Windows file explorer. You can suggest changes here : https://github.com/Basile-z/dexed/issues. The suggestion for the shell actions is already opened.
Re: D IDE dexed - v3.7.10 available
On Thursday, 13 June 2019 at 05:09:34 UTC, gleb.tsk wrote: On Monday, 10 June 2019 at 20:34:14 UTC, Basile B. wrote: [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10 Thank you, very interesting. But... lazbuild -B -r dexed.lpi TEditorToolBarOptions.Load: Using old configuration in editortoolbar.xml. Hint: (lazarus) [RunTool] /usr/bin/fpc "-iWTOTP" Hint: (lazarus) [RunTool] /usr/bin/fpc "-va" "-Fr/usr/lib64/fpc/msg/errore.msg" "compilertest.pas" Error: (lazbuild) Broken dependency: DexedDesignControls See https://github.com/Basile-z/dexed/issues/456. Unfortunately the reporter never gave any feedback so I had closed. All I know is that installing the package in Laz, then rebuilding Laz then building the project will work.
D IDE dexed - v3.7.10 available
A small update of this IDE dedicated to the D languages and its tools [1]. Only some small fixes and adjustments, see [2] for details and pre-compiled binaries. [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10
Re: The D Blog in 2018
On Sunday, 2 June 2019 at 20:08:28 UTC, Murilo wrote: Hi everyone. I don't mean to spam Sure otherwise you would not post this 3 times in a row: - https://forum.dlang.org/post/tjoipokamsvpbemzd...@forum.dlang.org - https://forum.dlang.org/reply/hebsehdcxhlhkzwxh...@forum.dlang.org
Re: Let's celebrate Dlang on D day
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote: On the 6th of June(6/6) we celebrate the D day on Normandy, but I have decided to turn it into our own holiday to celebrate the D language. So on this day please take the time to tell the world about this language and to invite more people into our community. I will try to give some talks at universities in order to get the attention of the people. I suggest you all do similar stuff. In the Dlang facebook group https://www.facebook.com/groups/662119670846705/ which has already reached 135 members, we will be doing lots of fun stuff. Please show up and join the group to participate. I will try to turn this into an actual holiday. I hope you can all help me out. I dont think it's a good idea. One of mine grandpa served in the french Marine when they destroyed the ships at Toulon. The other went from algeria, from a spanish colony, to here... This D day idea is completly stupid.
Re: D GUI Framework (responsive grid teaser)
On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote: Hi, we are currently build up our new technology stack and for this create a 2D GUI framework. https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0 The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms, drawing it about 10ms. The mouse clicks are handled via a reactive message stream and routed to all graphical objects that are hit using a spatial-index. The application code part is about 50 lines of code, the rest is handled by the framework. With all this working now, we have all necessary building blocks working together. Next steps are to create more widgets and add a visual style system. The widgets themself are style-free and wire-frame only for debugging purposes. What kind of layouting ? GTK-like ? DelphiVCL-like ? Flex-like ?
Re: D GUI Framework (responsive grid teaser)
On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote: On 2019-05-19 21:21:55 +, Ola Fosheim Grøstad said: Interesting, is each cell a separate item then? So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell? That's a lot of work. Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 I optimized the whole thing a bit, so now a complete screen with layouting, hittesting, drawing takes about 28ms, that's 8x faster than before. Drawing is still around 10ms, layouting around 16ms, spatial index handling 2ms. So this gives us 36 FPS which is IMO pretty good for a desktop app target. There might be some 2-3ms speed-up still possible but not worth the effort yet. openGL backend I presume ?
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
On Sunday, 1 July 2018 at 12:04:06 UTC, Basile B. wrote: I've recently ported libfirm to D. This nice C library, developed at the Karlsruhe university, allows to build compiler back-ends, using the SSA intermediate representation. In theory it could even be used to make a new D compiler version, e.g "FDC", although this is obviously of no interest ;) So this is mostly to make JIT scripting engines or back-ends for toy languages... See: - https://github.com/BBasile/libfirm-d - https://code.dlang.org/packages/firm-d - https://pp.ipd.kit.edu/firm/ Note that unfortunately this library is LGPL2 licensed, so much less usable than LLVM-d, which is a similar but a more mainstream library. With the recent release of dstep 1.0.0 I've managed to make a new minor release that only auto generate the sources (v0.1.0). It was obviously not a good idea to maintain all the headers up to date manually, although this permitted to learn a bit the API. Note that building must be done at least twice the first time because of a DUB limitation. other changes : - dub package on code dlang is gone, it must really be a git stuff now - it's much faster because build is optimized using git hashes. - location changed due to GH account renaming https://github.com/Basile-z/libfirm-d
Re: GDB + ddemangle
On Friday, 26 April 2019 at 07:08:45 UTC, Arun Chandrasekaran wrote: On Friday, 20 April 2018 at 17:55:12 UTC, Iain Buclaw wrote: On 20 April 2018 at 17:40, drug via Digitalmars-d-announce wrote: 20.04.2018 16:49, Iain Buclaw пишет: [...] it works, thank you. But not in all cases. For example when gdb stops on breakpoint it demangle, but if I do `bt` - backtrace isn't demangled. Using a compiler that implements 2.077 or later (IIRC) probably won't, due to gdb being too old. They broke ABI by introducing back referencing, no release of gdb supports that yet. This stays broken after 1 year. How do we fix this? I recognize your name from IRC, where you posted a related question yesterday. The person in charge for D in GDB had answered: The problem is that the mangling scheme has changed (to produce shorter mangles). Demangling will be eventually supported when D will be in GCC for good (GCC 10) and then he would port the demangling from GCC to GDB. So for now demangling of D in GDB only work if the binary is compiled with a very old version of the compiler, i.e prior to the new mangling method.
Re: The tools DCD 0.11.1, D-Scanner 0.7.1 and dfmt 0.10.0 are released
On Monday, 1 April 2019 at 07:22:52 UTC, Basile B. wrote: Note that DCD, when build with DMD 2.085.0 will likely crash a lot due to a bug in DMD backend Sorry this was inexact, DMD 2.085 + DUB. The versions build with make or the bat script work.
The tools DCD 0.11.1, D-Scanner 0.7.1 and dfmt 0.10.0 are released
DCD[1], D-Scanner[2] and dfmt [3] got updated today. You're invited to update them or wait that the plugin of your editor get a new release. See the links for changelog and binaries. Note that DCD, when build with DMD 2.085.0 will likely crash a lot due to a bug in DMD backend. I've managed to fix it earlier this month unfortunately we're still waiting for 2.085.1 to be released. If you want to say thanks, here is a link [4] for financial support of contributors of this releases (only). [1] https://github.com/dlang-community/DCD/releases/tag/v0.11.1 [2] https://github.com/dlang-community/D-Scanner/releases/tag/v0.7.1 [3] https://github.com/dlang-community/dfmt/releases/tag/v0.10.0 [4] https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick_button_id=AQDJVC39PJF7J Have fun Baz.
Re: DIP 1004--Inherited Constructors--Abandoned
On Wednesday, 6 March 2019 at 12:24:03 UTC, Mike Parker wrote: As part of a cleanup of the DIP queue, DIP 1004, "Inherited Constructors", has been marked as Abandoned. This means anyone willing to take it over and move it forward, including the original author, is free to do so. Given that this DIP was submitted under the old system and the length of time since the community review (then called "Preliminary Review"), any resurrection of this DIP would need to meet two requirements: * revision to use the current DIP template and, where appropriate, to apply feedback from the previous review (including my summary of the previous review round) * a new round of Community Review It would be appropriate to retain the same DIP number unless the DIP were rewritten from scratch, in which case it would need first to enter into Draft Review. https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1004.md What a pity, so much time lost for something many considered as guaranteed to be accepted because obvious and useful. While i remembered this DIP i completely forgot that its author has left the D scene. Plz someone, finish the work.
Re: Release D 2.085.0
On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote: Glad to announce D 2.085.0, ♥ to the 49 contributors. This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32. http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html ¹: There is a pending Objective-C fix (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will be released with 2.085.1 soon (~1.5 weeks). -Martin GoodBye Darwin 32. I wonder if the issues specific to this platform should be all closed as WONTFIX or left as is (example : https://issues.dlang.org/show_bug.cgi?id=13457)
Re: DCD 0.11.0 released
On Monday, 11 February 2019 at 20:40:32 UTC, notna wrote: Installing DCD Downloading from https://github.com/dlang-community/DCD/releases/download/v0.10.2/dcd-v0.10.2-windows-x86.zip to C:\Users\\AppData\Roaming\code-d\bin Failed installing: std.net.curl.CurlException@std\net\curl.d(4340): Peer certificate cannot be authenticated with given CA certificates on handle I don't know what you are talking about, how are you installing DCD ? What is the installer you talk about ? Also the version number of this release is 0.11.0, not 0.10.2
DCD 0.11.0 released
DCD, the best companion of your IDE is updated to v0.11.0 [1] Important changes in this release are enhancements from me on template parameters and ddoc, also fix on arrays semantic by CyberShadow. A little thanks would be welcome, either for me [2] or CyberShadow [3] [1] https://github.com/dlang-community/DCD/releases/tag/v0.11.0 [2] https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick_button_id=AQDJVC39PJF7J [3] https://forum.dlang.org/thread/ldhflkowunjguzgop...@forum.dlang.org
The DDOC generator Harbored-mod - version 0.3.0 available
The documentation generator harborded-mod just got second life. Version 0.3.0 comes notably with - a better default style that looks more like the official doc [1]. - many bug fixes. check [2] and [3] to get the sources and build it. Offer me free coffee or support my involvement in the dlang tooling [4] [1] https://basile-z.github.io/new-hmod-preview/iz.html [2] https://github.com/dlang-community/harbored-mod/releases/tag/v0.3.0 [3] https://code.dlang.org/packages/harbored-mod [4] https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick_button_id=AQDJVC39PJF7J
The D IDE dexed - version 3.7.5 available
See [1] to consult the changes since the last announce here. Maybe it was 3.7.2, I don't remember. [1] https://github.com/Basile-z/dexed/releases
Re: OT: LLVM talk @ FOSDEM'19
On Saturday, 2 February 2019 at 16:12:12 UTC, Kai Nacke wrote: Hi everybody! I am still around. :-) I am a speaker in the LLVM toolchain devroom @ FOSDEM'19. My talk is about how to easily generate IR for LLVM. Sorry - not D related this year but still useful. Read the announcement at https://fosdem.org/2019/schedule/event/llvm_irgen/. FOSDEM is a two-day event organised by volunteers to promote the widespread use of open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as "the best open source conference in Europe". FOSDEM 2019 will take place at ULB Campus Solbosch on Saturday 2 and Sunday 3 February 2019. Read more about the event at https://fosdem.org/2019/. Regards, Kai Thanks this topic interests me so i'll watch the cideo when available.
Re: D IDE "Dexed" - version 3.7.0 available
On Monday, 7 January 2019 at 20:56:27 UTC, Daniel Kozák wrote: I have tried to install it on archlinux but I get something else: http://asb2m10.github.io/dexed/ the archlinux package for mine doesn't exist.
Re: SecureD 2.0 Released
On Monday, 31 December 2018 at 03:54:31 UTC, Adam Wilson wrote: SecureD is a library that provides strong cryptography with a simple-to-use interface that ensures that your data will be correctly and securely stored with a minimum amount of effort. [...] Thanks it looks very complete.
DCD, D-Scanner and DFMT : new year edition
DCD [1] 0.10.2 comes with bugfixes and small API changes. DFMT [2] and D-Scanner [3] with bugfixes too and all of the three products are based on d-parse 0.10.z, making life easier and the libraries versions more consistent for the D IDE and D IDE plugins developers. [1] https://github.com/dlang-community/DCD/releases/tag/v0.10.2 [2] https://github.com/dlang-community/dfmt/releases/tag/v0.9.0 [3] https://github.com/dlang-community/D-Scanner/releases/tag/v0.6.0
Re: now it's possible! printing floating point numbers at compile-time
On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote: too bad that i didn't knew about Ryu back than. It's very recent, announce on proggit is < 1 year. It would be nice to have one to format in phobos. RYU or Grisu3 doesn't matter much as long as the two issues that are - CTFE formatting of floats - formatting is identical on all platforms is solved. There's also the "real" problem. I'm pretty sure that 32 and 64 bits floats are always handled. Someteimes 128 bits ones but not sure for 80 bits...
Re: Beta 2.084.0
On Tuesday, 25 December 2018 at 18:26:16 UTC, Andre Pany wrote: On Monday, 24 December 2018 at 22:33:27 UTC, Martin Nowak wrote: On 12/17/18 10:38 PM, Martin Nowak wrote: Second beta live now. Basile B. solved the spurious NOLOGO bug. Can you include it in 2.084? https://github.com/dlang/dmd/pull/9142 He doesn't have to include it because the fix has been merged in the stable branch, which is the one used to build the releases.
Re: DCD xmas edition
On Monday, 24 December 2018 at 17:15:43 UTC, ANtlord wrote: On Monday, 24 December 2018 at 13:24:30 UTC, Basile B. wrote: added support for completion on template type parameters that must implicitly convert to a type. You, sir, are my hero! That's funny ANtlord because the changes allowing this feature are ridiculous (see [1]), 4 SLOCs, that's not false modesty i rather think that it's something that Hackerpilot forgot to make at some point. [1] https://github.com/dlang-community/dsymbol/pull/109/files
Re: DConf 2019: Shepherd's Pie Edition
On Wednesday, 26 December 2018 at 11:26:52 UTC, Guillaume Piolat wrote: Last year I had an amazing time at Dconf. Went to bike there for 9 days (800km), to arrive the day before DConf. woah dude !
Re: DCD xmas edition
On Wednesday, 26 December 2018 at 21:31:52 UTC, WebFreak001 wrote: On Monday, 24 December 2018 at 13:24:30 UTC, Basile B. wrote: By some chances some cool new feature were added latest week, justifying a new minor release [1] [1] https://github.com/dlang-community/DCD/releases/tag/v0.10.0 really cool! Are the pre-compiled binaries getting added to it soon? I want to push this to code-d/serve-d before I release the next release. They used to be automatically generated. I don't know what has happened this time.
Re: Beta 2.084.0
On Monday, 24 December 2018 at 22:33:27 UTC, Martin Nowak wrote: On 12/17/18 10:38 PM, Martin Nowak wrote: Second beta live now. Can someone take a look at https://issues.dlang.org/show_bug.cgi?id=19510 ?
DCD xmas edition
By some chances some cool new feature were added latest week, justifying a new minor release [1] [1] https://github.com/dlang-community/DCD/releases/tag/v0.10.0
Re: now it's possible! printing floating point numbers at compile-time
On Saturday, 22 December 2018 at 20:24:46 UTC, Stefan Koch wrote: On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch wrote: Thus enabling you to convert doubles into strings at compiletime. Cool, CTFE formating is something that occasionaly comes in the forum. Now i remember there's also RYU [1] that could have worked too Aww I am dumb ... should have waited 2 days :) No because actually from a pagan point of view the big thing was yesterday night (solstice). Anyhow I hope that this is helpful to some of you. Please note that grisu 2 will give you representation which will convert into the same(!) floatingpoint number you passed in >92% of all possible inputs. Meaning you can round trip from string to double without loss of bits, for very many number but not all of them, that said the accuracy in general should be better than what a usual sprintf would give you. Cheers and Merry Christmas, Stefan [1] https://github.com/ulfjack/ryu
Re: Fuzzed - a program to find DMDFE parser crash
On Saturday, 15 December 2018 at 21:09:12 UTC, Sebastiaan Koppe wrote: On Saturday, 15 December 2018 at 15:37:19 UTC, Basile B. wrote: I think this is what Walter calls "AST poisoning" (never understood how it worked before today). And the whole parser is like this. This poisoning kills the interest of using a fuzzer. 99% of the crashes will be in hdrgen. As is common with fuzzing, you'll need to ensure the program crashes. Yes this is done by piping dmd with the random code (i dont use dmd as a library for now). If the process returns something different of 0 (ok) and 1 (normal compiler error) than the random code is saved in a file: ... ProcessPipes pp = pipeProcess([Options.dc, "-"]); pp.stdin.writeln(src); pp.stdin.close; if (!pp.pid.wait.among(0, 1)) fileName.write(src); ... Actually it would be less convenient to do that with the front end as a library, since SEGFAULTs are supposed to kill the program...
Re: Fuzzed - a program to find DMDFE parser crash
On Sunday, 16 December 2018 at 01:57:17 UTC, Walter Bright wrote: On 12/15/2018 2:48 PM, Neia Neutuladh wrote: The way to fix this is to replace the entire parser and get rid of the idea of AST poisoning; at the first error, you give up on parsing the entire file. From there, you can try recovering from specific errors with proper testing. DMD tries to continue parsing after a syntax error, but it does not attempt semantic analysis if there were any errors. The problem i underlined is more that, like in the code that parses typeof, a non null node is returned even if some expectations are not verified when parsing. I'm not sure of what is the right fix. fixing the ast pretty printer or the parser ?
Re: Fuzzed - a program to find DMDFE parser crash
On Saturday, 15 December 2018 at 22:48:01 UTC, Neia Neutuladh
wrote:
The way to fix this is to replace the entire parser and get rid
of the idea of AST poisoning; at the first error, you give up
on parsing the entire file. From there, you can try recovering
from specific errors with proper testing.
You can still continue parsing after an error but right now many
sub-parsers always return an AstNode instead of null. The parser
on null sub parser result could go to the end of the scope or to
the next statement, depending on what it expected, and continue
from there. That being said this wouldn't always work, e.g when a
semi colon or a curly brace misses.
Simple example:
struct Foo
{
int a, b
string c; // error because a type identifier part wasn't
expected ...
} // ... we're in a aggr body so consume toks
past the curly brace
struct Bar
{
}
Re: Fuzzed - a program to find DMDFE parser crash
On Saturday, 15 December 2018 at 14:22:48 UTC, Johan Engelen
wrote:
On Saturday, 15 December 2018 at 11:29:45 UTC, Basile B. wrote:
Fuzzed [1] is a simple fuzzer for the D programming language.
Are you familiar with libFuzzer and LDC's integration?
https://johanengelen.github.io/ldc/2018/01/14/Fuzzing-with-LDC.html
No, but i'm not that surprised to see that a fuzzer already
exists.
I may have even seen this article but completely forgot it.
You can feed libFuzzer with a dictionary of keywords to speed
up the initial fuzzing phase, where the keywords are the tokens
strings that you use.
Besides finding crashes, it's also good to enable ASan to find
memory-related bugs that by luck didn't crash the program.
The time to write this announce, already 5 "crashers" found.
Great :)
I have about 40 now
The other day I was reminded of OSS Fuzz and that it'd be nice
if we would setup fuzzing for the frontend and phobos there...
-Johan
I started looking at a crasher:
typeof function function in
which crashes in hdrgen. Actually i realize that i don't like the
D parser. In many cases it checks for errors but continues
parsing unconditionally.
In the example, "in" leads to an null contract that the pretty
formatter dereferences at some point, but parsing should have
stopped after "typeof" since there is no left paren. Now take a
look at typeof sub parser
AST.TypeQualified parseTypeof()
{
AST.TypeQualified t;
const loc = token.loc;
nextToken();
check(TOK.leftParentheses); // <-- why continuing if the
check fails?
if (token.value == TOK.return_)
{
nextToken();
t = new AST.TypeReturn(loc);
}
else
{
AST.Expression exp = parseExpression();
t = new AST.TypeTypeof(loc, exp);
}
check(TOK.rightParentheses);
return t;
}
I think this is what Walter calls "AST poisoning" (never
understood how it worked before today). And the whole parser is
like this.
This poisoning kills the interest of using a fuzzer. 99% of the
crashes will be in hdrgen.
Fuzzed - a program to find DMDFE parser crash
Fuzzed [1] is a simple fuzzer for the D programming language. It allows to detect sequences of tokens that crash the parser. While the D front end is not yet used to make tools, if this ever happens the parser will have to accept invalid code. As experienced with dparse, invalid code tend to crash more a parser because of a cognitive bias that lead us, "hoomans", to prove that things work rather than the opposite. You can run it on one your core, report the crasher programs to the project issue tracker or fix them yourself: gdb dmd run bt And then try to see what happens in the parser at the location pointed on top of the back trace. Note that you'll need to build dmd debug version. The time to write this announce, already 5 "crashers" found. [1] https://github.com/BBasile/fuzzed
Re: A facebook group for D programmers
On Monday, 10 December 2018 at 00:18:03 UTC, Murilo wrote: Hi guys, thank you for helping me out here, there is this facebook group for the D language, here we can help and teach each other. It is called Programming in D. Please join. https://www.facebook.com/groups/662119670846705/?ref=bookmarks No thanks. Facebook discussions are private, not referenced by search engines, so unhelpful for people who would come in the future with a problem that's been already solved over there. Things happen here, really.
Re: textattr library for text colors and attributes available in D
On Thursday, 8 November 2018 at 13:37:08 UTC, Shriramana Sharma
wrote:
https://github.com/jamadagni/textattr/
textattr is a library and command-line tool that makes adding
color and attributes to beautify the terminal output of your
program easier by translating human-readable specs into ANSI
escape codes.
The library is available for C, C++, Python and D. C++ and
Python use the C code for internal processing but the D code is
a separate implementation for easy inclusion of textattr.d in a
D compilation command without requiring any external linking.
Copyright: Shriramana Sharma, 2018
License: BSD-2-Clause
i was thinking to something like this the other day:
struct ColoredText(int color)
{
string payload;
alias payload this;
}
with a writeln() like function that check if the args are
template instances of ColoredText.
or even more versatile:
@Color!Blue string b1, b2;
@Color!Red string r1, r2;
@Color!Green int i1, i2;
with a writeln() like function that inspects the UDA or the args.
Re: Profiling DMD's Compilation Time with dmdprof
On Sunday, 18 November 2018 at 01:12:04 UTC, Vladimir Panteleev wrote: On Saturday, 17 November 2018 at 23:01:23 UTC, Basile B. wrote: I put a start to the project then today i remembered callgrind... What are the pros and cons in comparison with callgrind ? By coincidence i had to callgrind dmd today and got answers to a performance issue in a very straight forward way because for example: $ valgrind --tool=callgrind generated/debug/dmd somefile.d is very simple procedure and produce a file that's easy to interpret in kcachegrind (which can then also produce a graph in ps format). Note that i don't try to discredit your work, i'm just curious to know. It sounds like you misunderstood the purpose of dmdprof. dmdprof will show you a profile graph of the source code *being compiled* (i.e. which parts take more time to compile and which parts cause other parts to get compiled), not of DMD source code. Damn, you're right. Actually i didn't try your stuff at all and instead used callgrind intuitively. Bad advice was here: https://github.com/dlang/dmd/pull/8945#issuecomment-439388332. Also along the thread there was discussion about building DMD and one saying that DMD had not been profiled for ages.
Re: Profiling DMD's Compilation Time with dmdprof
On Tuesday, 6 November 2018 at 18:00:22 UTC, Vladimir Panteleev wrote: This is a tool + article I wrote in February, but never got around to finishing / publishing until today. https://blog.thecybershadow.net/2018/02/07/dmdprof/ Hopefully someone will find it useful. I put a start to the project then today i remembered callgrind... What are the pros and cons in comparison with callgrind ? By coincidence i had to callgrind dmd today and got answers to a performance issue in a very straight forward way because for example: $ valgrind --tool=callgrind generated/debug/dmd somefile.d is very simple procedure and produce a file that's easy to interpret in kcachegrind (which can then also produce a graph in ps format). Note that i don't try to discredit your work, i'm just curious to know.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote: On 10/15/2018 2:23 PM, Walter Bright wrote: I'm giving a presentation at: http://nwcpp.org/ See you there! Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf https://www.reddit.com/r/programming/comments/9qbhw2/nwcpp_walter_bright_talks_about_the_code_smells/
DCD 0.9.13 and D-Scanner 0.5.11
See detailed changelog and pre-compiled binaries: https://github.com/dlang-community/DCD/releases/tag/v0.9.13 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.11 DCD update highly recommended if you're still on v0.9.11 or older.
Re: DCD 0.9.11 & D-Scanner 0.5.10
On Sunday, 2 September 2018 at 04:52:22 UTC, Basile B. wrote: Both compatible with syntax changes coming with 2.082. https://github.com/dlang-community/DCD/releases/tag/v0.9.11 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.10 Better use https://github.com/dlang-community/DCD/releases/tag/v0.9.12
Re: DCD 0.9.11 & D-Scanner 0.5.10
On Sunday, 2 September 2018 at 15:45:45 UTC, Nordlöw wrote: On Sunday, 2 September 2018 at 04:52:22 UTC, Basile B. wrote: Both compatible with syntax changes coming with 2.082. https://github.com/dlang-community/DCD/releases/tag/v0.9.11 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.10 Great! Professional. Well thnaks but, hum, actually DCD 0.9.12 is coming directly today. There was an indescribable mess with scopes. For example try ``` import core.thread; Thread t; t. ``` the dot completions for t are completely wrong and many stuff miss.
DCD 0.9.11 & D-Scanner 0.5.10
Both compatible with syntax changes coming with 2.082. https://github.com/dlang-community/DCD/releases/tag/v0.9.11 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.10
Re: GDC with D frontend 2.081.2
On Friday, 24 August 2018 at 05:35:13 UTC, Eugene Wissner wrote: As some of you may know D frontend was merged into GDC some time ago and is up to date. D version currently supported by GDC is 2.081.2 Great news. Best of luck for a wide adoption in the official package managers of the linux distributions.
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote: Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please? And drop completion call tips etc at the same time...
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
On Thursday, 5 July 2018 at 00:00:07 UTC, Chris M. wrote: On Sunday, 1 July 2018 at 12:04:06 UTC, Basile B. wrote: I've recently ported libfirm to D. This nice C library, developed at the Karlsruhe university, allows to build compiler back-ends, using the SSA intermediate representation. Very nice, I remember checking this one out a while back. I don't see the files from the ADT module though, was there a reason they weren't included? https://github.com/libfirm/libfirm/tree/master/include/libfirm/adt Yes there's a reason that is that these files mostly contain data structures, they are not needed in D and i don't remember having seen them as parameter type during translation of the headers, (although it's been done semi manually, so i could have missed one).
