Re: DotfiM v0.0.1 - A dotfile manager
On Tuesday, 3 July 2018 at 16:31:39 UTC, Francesco Mecca wrote: On Saturday, 30 June 2018 at 14:27:39 UTC, Timoses wrote: Thought I'd try a release of this project of mine which I find very useful. https://github.com/Timoses/dotfim DotfiM is capable of syncing your dotfiles across machines via a git repository. Simply download DotfiM, build it and run `dotfim sync `. DotfiM asks if you would like to install all the dotfiles in the git repository to your local home folder. DotfiM is very useful if you set up your environment via dotfiles. This could include your vim setup or how your shell looks and behaves. The goal of DotfiM is to take your environment setup anywhere you go. DotfiM will create two sections in a synced dotfile: - One section is synchronized to the git repository - another is only kept locally I'd be thrilled to hear if it works for you. Let me know of any issues or ideas you might have. Note that I've started this project almost a year ago when I was still in "Dinfant shoes". What is a dotfile? Basically, it's a configuration file on UNIX systems and can be used to customize your environment. It would be interesting if you highlights the difference between the traditional stow approach: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html On top of my mind I have this questions: Are you using symlinks? Can I sync parts of the dotfiles? I must admit, I didn't look around much for dotfile management tools before implementing DotfiM. I just jumped at the opportunity for a D project. Compared to Stow I'd highlight the following differences: - DotfiM doesn't use symlinks, instead contents of the gitfiles (the dotfiles saved in the git repository) are thrown into your home directory while keeping already existing content of the dotfile (in the home directory) in a local "section". In effect the dotfile then contains two sections, one which is synced with the git repo and one which is kept only locally. The resulting dotfile in the home directory will look something like this: # This dotfile is managed by DotfiM #-DotFiM-# # DotfiM - Git Section # Changes to this section are synchronized with your dotfiles repo # Git Commit Hash: aaa19f7f595bc9f0d6e5bdbeb1b8a1f93cdfe803 # - - - - - - - - - - - # My synced setups ... # - - - - - - - - - - - # DotfiM - end of Git Section #-DotFiM-# #-DotFiM-# # DotfiM - Local Section # This section is only kept locally and will not be synced # - - - - - - - - - - - # Any stuff only locally applied # - - - - - - - - - - - # DotfiM - end of Local Section #-DotFiM-# If you decide that you no longer want to sync the dotfile just do `dotfim remove ` and it'll remove the synced part and only leave the local section in place. Since all content of the synced section is already synced to the git repo, nothing should be lost. - So, compared to Stow the git repository is organized as a "mirror" of the actual dotfile repository and not organized in packages. - Lastly, DotfiM automatically syncs your changes to the dotfiles in the home folder when running `dotfim` and takes over all the fetching and pushing to the git repository. How does Stow work when you already have an existing file and install another? Symlinking would delete the old file and just replace it with a symlink to the new file in the stow package? Implementing something like profiles could be interesting, though I haven't had the need for it so far and therefore also didn't think of any strategy of implementing such a feature.
Re: I have a plan.. I really DO
Throw everything we can this dude's way so we can make D the most powerful we can We need pattern matching, we need typeclasses, we need HKT's, we need linear types, we need @nogc Phobos, we need concurrency so fearless I can change any variable and not give two shits Personally I don't really NEED pattern matching, typeclasses, etc That would be nice, but personally that wouldn't prevent me from getting the job done. But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. So being able to add a "-nogc" flag to the DMD compiler and use a minimal Phobos-like library (strings, arrays, lists, maps and other collections, file system functions, etc) which use EXCLUSIVELY reference counted memory block accessed through strong/weak references and pointers (T@, T&, T*) would be nice. Not an implementation like the one in the standard library of C++, which is maybe safe but not especially efficient or user friendly, but preferably something closer to this : https://github.com/senselogic/BASE/tree/master/CODE/COUNTED And being able to DIRECTLY use D with REAL Go-like ease of use and performance (http components, fibers and channels using both concurrency and parallelism) to implement web frameworks and online services is also something many people may NEED.
Re: DotfiM v0.0.1 - A dotfile manager
On Saturday, 30 June 2018 at 14:27:39 UTC, Timoses wrote: Thought I'd try a release of this project of mine which I find very useful. [...] Dot files are usually very personalized. I wonder what DotfiM can do more than cloning and linking stuffs.
Release D 2.081.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.081.0. This release comes with... http://dlang.org/download.html http://dlang.org/changelog/2.081.0.html - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAls8m4QACgkQsnOBFhK7 GTnB8xAAuEYsoJZOSef8XLuVY9Jzr6zLEzQvei8jbybtCC8UlsNQjE2vrvCIEbQ8 +YRgiQC9c0ivnmz/qSX2bnUjqnQwNpRCBOh5kF/eqWs9PqE6hLJ1nXbBg5ndksvh WmIjvFf2pU6/su1zE/CRJhYDL6cLOiMJp3sPFc1eci4oVVrBi1jvOA+yoszvxFvC l1CbtXarUKLmWa6ogY4IvZOnvR01lotSfmzYhF4U/wozUxrJD5mYhtOTz3Uf1Qr1 6Pu7BQl0PYh9BcqCPGg0G2ctQ48WVdLdEGfjUMTYsdVaWXGqGLEcl1cV4tRIRrgH kUVRqLlDNO8jKZbBYpnwxjrxsfzBVJ0JALGltFxlCXzOAJzFprugC5k9flijxEGH cC+A+WQ6wMpym1zzO51dvduFFUu8fNSAV2sefEm6McnujbHubx4tfZDainTkYU/D AAyzZiP6JHntRrRHdTy0zT6/WK4UxLID36fBJZKH0YAT3vPe5NzwoUZ4iTISWeLw i4QxAn8GQw0/E+DM5S9KsB5Wi8osKQPuEiu5nUTKMZQUuuWjVWf2JdEnVTY9HGoG mCtK/GT2B8QUPurkTwuRK55uEPJAyVL12fzBk05mxR8kjWD5ETARRez4+V5htZxU hK6vT+ciiiDf4AvzkYf/1pSHYRQcbUfIaNnW3X+RO2M7SerBoJw= =z+2F -END PGP SIGNATURE-
Re: Release D 2.081.0
On Wednesday, 4 July 2018 at 10:03:57 UTC, Martin Nowak wrote: Glad to announce D 2.081.0. This release comes with... http://dlang.org/download.html http://dlang.org/changelog/2.081.0.html - -Martin thx, keep on "git gud".
Re: Release D 2.081.0
On Wednesday, 4 July 2018 at 10:09:27 UTC, Basile B. wrote: On Wednesday, 4 July 2018 at 10:03:57 UTC, Martin Nowak wrote: Glad to announce D 2.081.0. This release comes with... http://dlang.org/download.html http://dlang.org/changelog/2.081.0.html - -Martin thx, keep on "git gud". sorry, i didn't get the negative meaning. Meant "keep on going"
Re: Release D 2.081.0
On 07/04/2018 12:03 PM, Martin Nowak wrote: > Glad to announce D 2.081.0. > > This release comes with... Improved C++ compatibility (https://dlang.org/changelog/2.081.0.html#extern_cpp_overhaul) DIP1009 - Expression-Based Contract Syntax (https://dlang.org/changelog/2.081.0.html#expression-based_contract_syntax) Lazy TypeInfo generation for interfaces and classes (https://dlang.org/changelog/2.081.0.html#min_runtime_classes) File names and line numbers for OSX stacktraces (https://dlang.org/changelog/2.081.0.html#backtrace_debug_info_macos) Custom local package repositories for dub (https://dlang.org/changelog/2.081.0.html#customCachePaths) > http://dlang.org/download.html > http://dlang.org/changelog/2.081.0.html > > -Martin >
Re: DotfiM v0.0.1 - A dotfile manager
On Wednesday, 4 July 2018 at 09:36:18 UTC, biocyberman wrote: On Saturday, 30 June 2018 at 14:27:39 UTC, Timoses wrote: Thought I'd try a release of this project of mine which I find very useful. [...] Dot files are usually very personalized. I wonder what DotfiM can do more than cloning and linking stuffs. Currently not much more. "Personalization" is the keyword I guess, at least in my use case. For example I use it to have the same setup on different machines for my - tmux (navigation setup, ...) - vim (.vimrc, filetype setup, plugin stuff which will auto load everything on first start of vim, key bindings, ...) - zsh (prompt, ...) - ssh configuration (e.g. aliases for remote hosts) - general git configuration (different logging styles, my user details, my github username when connecting to github, ...) Whenever I optimize my setup I just have to run `dotfim` and it'll automatically be synced to any other machine I succeedingly run `dotfim` on. Currently, I have it set up so that any time I log into a shell on a computer it runs `dotfim` automatically, and once again when I log out.
Re: Release D 2.081.0
On Wednesday, 4 July 2018 at 10:03:57 UTC, Martin Nowak wrote: Glad to announce D 2.081.0. This release comes with... http://dlang.org/download.html http://dlang.org/changelog/2.081.0.html - -Martin The blog announcement: https://dlang.org/blog/2018/07/04/dmd-2-081-0-released/ Reddit: https://www.reddit.com/r/programming/comments/8w27kn/version_20810_of_the_d_reference_compiler_dmd/
Re: Release D 2.081.0
On Wednesday, 4 July 2018 at 14:55:56 UTC, Mike Parker wrote: On Wednesday, 4 July 2018 at 10:03:57 UTC, Martin Nowak wrote: Glad to announce D 2.081.0. This release comes with... http://dlang.org/download.html http://dlang.org/changelog/2.081.0.html - -Martin The blog announcement: https://dlang.org/blog/2018/07/04/dmd-2-081-0-released/ "much quiter"
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. This has to be the no. 1 excuse. Why is C++ the language of choice currently? My bet is productivity and economic concerns. Amongst other things the productivity gain from resource management via constructor and destructor. Which solves like 75% of the headaches of manual resource management and goto nightmares. Back in the day when C was used to make games, the excuse not to use C++ was vtable, exception and RTTI overhead. Now it's called the bare metal best performance language which everything and their grandma is measured against. This C++ overhead didn't make C any slower or C++ any faster than C but it made C++ superior in productivity. This was around 2002/03, and C++, at the time, some 23+ years old. Games have been made with GC'd languages, 3D games, even. And successfully, too. Minecraft, a very successful one, comes to mind, which is or at least was made in Java. Plenty of games are made in C#, too. My bet, again, would be productivity and economic concerns. The countless hours wasted on debugging memory leaks and cyclic dependencies are better spent making the actual game/software. And smart pointers introduce overhead of their own which makes them inferior to C's bare metal raw pointer performance - or GC'd pointers for that matter. The culprit being the collection cycle. The best thing about this whole argument, however, is the claim for GC no can do and with the next breath they pull LUA into their games. A scripting language that brings a VM, GC and extraordinarily inflated loading times when the scripts are compiled to byte code at the end user's PC which make C64 loading times shine. The reasoning probably being productivity again and C++'s lunch break compile times. Using the D compiler as a library, instead of LUA, D code could be used for 'scripting', as well, and compiled to native machine code. In a snap. I have no metrics between any AAA game engine and their port to D but I do know that I wrote a sound/music player library in Java, which folks like you claim impossible because GC, never bothered with GC and had no performance issues whatsoever - and I don't expect any porting it to D. And there is EASTL. A STL made by Electronic Arts. Because the standard implementation shipped with the compiler is too slow ? Even though written by C++ wizards ? Slow code is slow and allocating memory in a tight loop is a huge performance killer - regardless of language. Also, why do you feel like a GC is inacceptable for games but doesn't matter for your file handling program? Handling dozens, maybe thousands, of files sounds like an awful lot of memory management involved and whether a e.g. grep takes 15 seconds to do it's job or under 1 matters not? Nothing forces anyone to use the GC, memory can be managed manually via malloc/free and you get to do it with scope statements/nested functions which makes it nicer than in C. You could also implement shared/weak ptr stuff in D - warts and all. If you need a GC free standard library, I believe there is an ongoing effort -or several- at code.dlang.org and probably other places. You said do this and that, GC, etc. to motivate C++ folks to come to D. I say it's an excuse not to use D and no matter the effort of advertising, a GC free phobos, etc. on part of the D-Lang Foundation and contributors would make these folks switch. They would simply find a different excuse. And where's the usefulness of toy examples like 2 line web servers which essentially do nothing? And how is that helping with getting attention from the game devs ? Putting on the front page a 12 line maze game which can be imported from the standard library? Not using the GC?
Re: I have a plan.. I really DO
On Wed, Jul 04, 2018 at 06:05:15PM +, wjoe via Digitalmars-d-announce wrote: > On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: > > But indeed, being able use D in a GC-free environment (like C++ and > > Rust do) would be something many people may NEED, for instance to be > > able to EASILY use D for soft-realtime applications like games. > > This has to be the no. 1 excuse. +1. It's typical GC-phobia that is mostly subjective and only tenously backed by real evidence. [...] > The best thing about this whole argument, however, is the claim for GC > no can do and with the next breath they pull LUA into their games. A > scripting language that brings a VM, GC and extraordinarily inflated > loading times when the scripts are compiled to byte code at the end > user's PC which make C64 loading times shine. Spot on! [...] > You said do this and that, GC, etc. to motivate C++ folks to come to > D. I say it's an excuse not to use D and no matter the effort of > advertising, a GC free phobos, etc. on part of the D-Lang Foundation > and contributors would make these folks switch. They would simply find > a different excuse. [...] Exactly. As Walter has said before, (and I paraphrase,) it's far more profitable to cater to *existing* customers who are already using your product, to make their experience better, than to bend over backwards to satisfy the critical crowd who points at issue X and claim that they would not use D because of X. But X is not the *real* reason they don't want to use D; it's just an excuse. Once you solve problem X, they will find issue Y and say *that* is the reason they're still not using D. And if you solve Y, they will find issue Z. It never ends, and you're wasting your efforts on non-customers who will *never* become customers. Why bother? Far better to improve things for existing customers (who may then get you new customers by word-of-mouth of their success stories -- *eager* new customers who aren't just looking for the next excuse not to use D). T -- They pretend to pay us, and we pretend to work. -- Russian saying
Re: DVM - D Version Manager 0.4.4
On 2018-07-03 03:34, Tony wrote: Thanks, that worked! It doesn't announce where it put the compiler, which turns out to be: C:\Users\\AppData\Roaming\dvm\ You're not supposed to know where it puts the compiler. You're activating it with "dvm use " where "" is the version you want to activate. This will persist for the end of the shell session. To set a default compiler use "dvm use -d". This allows to use separate versions simultaneously in different shell sessions. See the usage information [1]. [1] https://github.com/jacob-carlborg/dvm#use-a-compiler -- /Jacob Carlborg
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote: On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. This has to be the no. 1 excuse. Why is C++ the language of choice currently? My bet is productivity and economic concerns. Amongst other things the productivity gain from resource management via constructor and destructor. Which solves like 75% of the headaches of manual resource management and goto nightmares. Back in the day when C was used to make games, the excuse not to use C++ was vtable, exception and RTTI overhead. Now it's called the bare metal best performance language which everything and their grandma is measured against. This C++ overhead didn't make C any slower or C++ any faster than C but it made C++ superior in productivity. This was around 2002/03, and C++, at the time, some 23+ years old. Games have been made with GC'd languages, 3D games, even. And successfully, too. Minecraft, a very successful one, comes to mind, which is or at least was made in Java. Plenty of games are made in C#, too. My bet, again, would be productivity and economic concerns. The countless hours wasted on debugging memory leaks and cyclic dependencies are better spent making the actual game/software. And smart pointers introduce overhead of their own which makes them inferior to C's bare metal raw pointer performance - or GC'd pointers for that matter. The culprit being the collection cycle. The best thing about this whole argument, however, is the claim for GC no can do and with the next breath they pull LUA into their games. A scripting language that brings a VM, GC and extraordinarily inflated loading times when the scripts are compiled to byte code at the end user's PC which make C64 loading times shine. The reasoning probably being productivity again and C++'s lunch break compile times. Using the D compiler as a library, instead of LUA, D code could be used for 'scripting', as well, and compiled to native machine code. In a snap. I have no metrics between any AAA game engine and their port to D but I do know that I wrote a sound/music player library in Java, which folks like you claim impossible because GC, never bothered with GC and had no performance issues whatsoever - and I don't expect any porting it to D. And there is EASTL. A STL made by Electronic Arts. Because the standard implementation shipped with the compiler is too slow ? Even though written by C++ wizards ? Slow code is slow and allocating memory in a tight loop is a huge performance killer - regardless of language. Also, why do you feel like a GC is inacceptable for games but doesn't matter for your file handling program? Handling dozens, maybe thousands, of files sounds like an awful lot of memory management involved and whether a e.g. grep takes 15 seconds to do it's job or under 1 matters not? Nothing forces anyone to use the GC, memory can be managed manually via malloc/free and you get to do it with scope statements/nested functions which makes it nicer than in C. You could also implement shared/weak ptr stuff in D - warts and all. If you need a GC free standard library, I believe there is an ongoing effort -or several- at code.dlang.org and probably other places. You said do this and that, GC, etc. to motivate C++ folks to come to D. I say it's an excuse not to use D and no matter the effort of advertising, a GC free phobos, etc. on part of the D-Lang Foundation and contributors would make these folks switch. They would simply find a different excuse. And where's the usefulness of toy examples like 2 line web servers which essentially do nothing? And how is that helping with getting attention from the game devs ? Putting on the front page a 12 line maze game which can be imported from the standard library? Not using the GC? First, to be clear, I mainly use D as a scripting language for file processing, and for this use case, having a GC is a blessing. You say that garbage collection is not a real problem for game development. Maybe, but that's not my experience. For instance, have you read Unity's own official recommandations on how to overcome this problem ? And obviously, Tibur, a highly skilled D game engine developer, is not a big fan of D's non incremental garbage collector, from the number of @nogc he has put in his Dlib container code. Maybe you disagree with us because you are a professional game developer who has already released a successful commercial game in D without caring for the garbage collection. If it's the case, then nice, I'd be happy to have it wrong on this :) And about developing video games in C++, actually most studios use orthodox C++. This means no exceptions, no RTTI, few virtual methods
Re: I have a plan.. I really DO
Exactly. As Walter has said before, (and I paraphrase,) it's far more profitable to cater to *existing* customers who are already using your product, to make their experience better, than to bend over backwards to satisfy the critical crowd who points at issue X and claim that they would not use D because of X. But X is not the *real* reason they don't want to use D; it's just an excuse. Once you solve problem X, they will find issue Y and say *that* is the reason they're still not using D. And if you solve Y, they will find issue Z. It never ends, and you're wasting your efforts on non-customers who will *never* become customers. Why bother? Far better to improve things for existing customers (who may then get you new customers by word-of-mouth of their success stories -- *eager* new customers who aren't just looking for the next excuse not to use D). +1 For instance, to be a perfect C++ alternative, D would probably need to be 100% : 1. usable (strings, slices, etc) without GC 2. interoperable with any existing C++ library For for game development : 3. compilable on all game development platforms (Win/Mac/Linux/Android/iOS/Switch/PS4/etc) I don't know if this can be achieved, or if this is really worth the effort.
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 19:49:00 UTC, Ecstatic Coder wrote: For instance, to be a perfect C++ alternative, D would probably need to be 100% : 1. usable (strings, slices, etc) without GC 2. interoperable with any existing C++ library For for game development : 3. compilable on all game development platforms (Win/Mac/Linux/Android/iOS/Switch/PS4/etc) I don't know if this can be achieved, or if this is really worth the effort. I think it isn't. Language is only a small part of the equation nowadays. The ecosystem is more important. If you made strings, slices etc. usable without GC, you'd probably make it incompatible with 90% of the existing code. The ecosystem would be split into "no GC" and "GC" libraries. And then you'd have the "C++ folks" complaining about how it's hard to tell what is supported, what isn't. If you aren't decisive, you open yourself to others doubting you. Look at C#, Java, Javascript. They have GC, do people complain about it? For the most part no, they just learned to deal with it and other language features make it worth it for them. These languages don't really consider adding advanced manual memory management options to lure in "C++ folks". Neither Unity is rewriting their engine in Rust as of this moment.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: I never ever (I think) did something provocative, something to finally see: ... My 5 cents inspired by experimenting with D some years ago. 1. Programming became niche oriented and quite diverse. Writing new language requires significant manpower. 2. D manpower is not sufficient for finishing language in low level niche. AFAIK Walter estimated manpower around 2013 to be equivalent of bus factor of 10. This is not enough to deliver stable language, it will always be "tasted as raw" comparing with c++. 3. D strategic mistake is ad-hoc design. Some features are added or extended and because of complexity result in corner cases (this is exacerbated because sometimes backward compatibility is preserved and sometimes not). Fixing corner cases sometimes produces more questions. As a result language has some mess which is unlikely to be fixed coherently (c++ is at least a documented mess). 4a. Limited developers' efforts are consumed by fixes and internal code optimization rather than important issues. 4b. Dips (related to language design) mostly fail because proposal authors do not write code and developers are busy. 5. My view of D future. Walter and developers will continue to improve and develop D but at low pace. Low-level niche will be dominated by c++ as a common denominator. D and some alternative languages would compete for different parts of this niche. In long-term low-level niche will be broken into smaller niches with languages specializing in them. Being "just low level" would be wrong as "just language". This would raise questions what D goal is. I am from area of economic, financial and scientific calculations used in decision making. It is dominated by python, c++ and statistical software. In most cases it does not require absolute speed (except financial markets rt trading, big data processing or some hard mathematical problems which are relevant for researchers in top institutions with supercomputers). It is hard for me to provide arguments for using D (meaning from professional area view) because c++ can be used for performance and D is poor in statistical libraries. Because it is applied area nobody cares whether exceptions have root class or whether virtual is default.
LDC 1.11.0 beta
Glad to announce the first beta for LDC 1.11. * Based on D 2.081.0. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0-beta1 Thanks to all contributors!
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. 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
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote: Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. Right, i have used the wrong words. Title hopefully is not ambiguous.
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).
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
Basile B. wrote: On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote: Basile B. wrote: I've recently ported libfirm to D. great news and great work, thank you. yet i must admit that wrapping != porting. Right, i have used the wrong words. Title hopefully is not ambiguous. ah, tbh, i'm just being jealous. you did my work! me is useless now!
