Re: Any book recommendation for writing a compiler?
Thanks for those references! I'm also interested in looking through those. I had computation theory in college a long time ago but never took a compiler course. On 11/7/2017 5:26 AM, Tony wrote: Author Allen Holub has made his out-of-print book, Compiler Design in C, available as a free pdf download: http://holub.com/compiler/ And Torben Mogensen is doing the same with his more recent Basics of Compiler Design: http://www.diku.dk/~torbenm/Basics/ --- This email has been checked for viruses by AVG. http://www.avg.com
Re: How about a bounty for a new windows installer using inno setup ?
On 12/8/2016 3:03 AM, Thomas Mader wrote: Do you think it would be possible to use D instead of C++ to write custom code? Custom code where? During the process of building the installation package or during installation itself. Anyway, in either case I don't see why not. You can insert a DLL into an MSI file. Then at some point during installation that you specify, the DLL will be extracted and an arbitrary function in it called. So any language that can generate a DLL will work there.
Re: How about a bounty for a new windows installer using inno setup ?
On 12/6/2016 10:31 PM, Thomas Mader wrote: The update case could be better supported by Inno by default though I don't know how to really do it transactionally/atomic. Once everything is on the drive, how would you be able to switch from the old directory to the new one with one atomic action under Windows? I'm not sure what you mean by switch the directory. If you mean that the update uses a different directory for the program than the original, then you can probably just use a "major" upgrade. Windows Installer has the idea of minor upgrade and major upgrade. (So, it's independent of whatever tools your using.) A minor upgrade just updates the files that have changed. A major upgrade essentially removes the original product totally and installs the new one. Some people even use a major upgrade for _every_ new version just to avoid problems that might occur with a minor upgrade. If your install is simple it may not matter whether it's transactional or not. If it fails halfway through just try again or else ask the user to delete files. But for a more complicated install it's possible that it fails halfway through and leaves the system in a bad state where the half-install cannot be easily removed nor can you try again because the installer now thinks the product is already installed. Trying to fix this on a remote user's system can be a headache. I liked WiX because it was down to the metal and I don't think there's anything you can't do. With other tools (like InstallShield) I spent too much time trying to get the tool to do something I could have done really easy at the low level if I could've just gotten to it. But granted, for simpler install situations the scripting tools can work OK and have a smaller learning curve. Jim
Re: How about a bounty for a new windows installer using inno setup ?
On 12/6/2016 12:21 AM, Thomas Mader wrote: You can also create a WiX installer out of an InnoSetup installer. I think it's more important to decide upon the feature set, readability and the time needed to build an installer. Have you experience with both? I only have experience with NSIS and InnoSetup and in InnoSetup the feature set for Windows is really good and the readability is good. I started out by using InstallShield some years ago and got battle scars there. I don't recommend that. I used NSIS a little because a company we partnered with required it but I'm no authority on NSIS or Inno. It really depends on how complicated your particular install is and where you expect it to go in the future. If you're just copying a few files then anything will work. I don't mean to make too big a deal out of it if the requirements are really simple. Personally I think it's better in the long run to generate an MSI for several reasons you can probably look up yourself---security, ability to rollback (installation is a transaction), appears in Programs and Features, transforms, etc. I wouldn't advise doing the coding part externally in D this makes things much more complicated than it should be. Stick with what's supported by the tool. I'm not suggesting you necessarily use D together with something like NSIS. But you do want to have a one-button automated build process, not just for convenience but for repeatability. That's important. Soon you will want to get away from the tool's own GUI and run things programmatically. After having not-so-good experiences with InstallShield I looked at things like SCons and msbuild, which was just coming out at the time. (This was a while ago). I tried msbuild but it didn't have modules to support many of the things I needed to do. Things like code-signing with a verisign signature, injecting data and files into exe resources, etc. Fortunately you can build your own custom modules using C# which is what I tried. But the process of transferring variables back and forth from the script to C# for every custom module was painful and I thought, "if I just do this all in C# it will be much easier". So I switched. I used C# not only to call on the WiX tools to run them, but to easily manipulate pathname and filename strings, which were different because I needed to build different configurations for different customer companies. And I also needed to build different combinations of language localization. I could use .NET to build a nice GUI for selecting configurations, and C# to call the Windows API when needed, move files around, anything. You may also run into issues when you need to do complicated updates and there are already earlier versions in the field. You may want to remove features, but your installer has to both update existing users in addition to supporting new users. It's hard to predict the future though so I won't say much about it except that it helps to have a more powerful tool when you run into such situations. The scripting-type tools are tempting because they're easy and no one wants to spend any time on installers. It's usually something that people hope to just slap on at the end and it often gets underestimated. But as I said, maybe it IS easy if you're just copying files and you will only ever have one configuration. So it depends. Jim
Re: How about a bounty for a new windows installer using inno setup ?
On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote: On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. wrote: How about a bounty for a new windows installer using inno setup ? There are several issues related to the nsis-based windows installer (even on bugzilla). The problem that happened last Fall with a virus false detection may happen again. "Braddr" proposed to handle digital signatures in case it would involve payment. Programming an installer is a small job but it has a long term impact on the user experience. Worth 100€ imo. Any particular reason to use Inno Setup over for example Wix Toolset? In my last job I worked on installers (which I didn't like but someone had to do it.) I recommend WiX over Inno. The main reason is that WiX produces an MSI and Inno doesn't. An MSI is just a data file, not an executable, and is thus better for security. I normally wrapped the MSI in a bootstrap exe. But we had one customer that was part of the government and wouldn't accept anything but an MSI. If you want, you can generate the XML with a program. I just didn't because I figured it was easier to modify if you can directly see the XML. My install builder was actually a combination of C# and WiX. I never found scripts to be flexible enough and it's just one more language to know. Jim
Re: Andrei's list of barriers to D adoption
On 6/6/2016 9:31 AM, Shachar Shemesh wrote: With the *possible* exception of C#, none of those are systems programming languages. D presents itself as one. Shachar I think that is true. I understand that some disciplines might need to avoid a GC for whatever reason, like games or small embedded systems. But the thing that always gets me about GC is not performance. It's that garbage collection always lumps all resources together with memory. I understand that there have been countless long discussions about GC. But my eyes glaze over because the discussion is usually about performance. Coming from C++ I like to use RAII. I like to depend on deterministic destruction of resources. I don't care about memory or when it's released (depending on the type of application) but I do care when other types of resources are released. If I'm wrong to be thinking this way I'm happy to be convinced otherwise. I know the library has Unique which is in std.typcons. But I thought I also read once that there are certain cases where it doesn't always work correctly. Maybe I'm mistaken; I'm not clear on that. As a developer coming from C++, okay, I've bought into the idea that D is a better C++. The first thing I want to know is, "How do I accomplish all the things in D that I normally do in C++?" For the case of deterministic destruction it might take someone a while to figure that out. (Not scope guards; they don't handle lifetimes longer than functions.)
Re: D 2015/2016 Vision?
On 10/8/2015 11:56 AM, Ola Fosheim Grøstad wrote: On Thursday, 8 October 2015 at 18:19:51 UTC, Jim Hewes wrote: Yes, there are libraries, but for it to be pleasant I think language support is needed. I've linked to this video before, but it is quite entertaining if you haven't seen it yet: https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask Yeah, I watched that after I saw your other post with the link. Thanks. One early question that I have (that someone else also asked in a comment below the video) is about design and the granularity of actors. What sorts of things do you define as an actor? How big does an entity need to be before you should make it an actor? Carl Hewitt stresses the difference from other concurrency models that use non-determinism by pointing out that a key quality with actor based systems is indeterminism. (i.e. that things may simply evaporate without notice). Another thing I noted was when he said once you get to 1000 cores the programmer knows nothing about the environment. So rather than figure out new ways to manage these things like locks and threads, it makes sense to get to a more abstract level where you don't even deal with it at all anymore. I don't know much about C++ actor frame works, but if you only want to play with actors then you could give pony-lang.org a spin. Not sure if they really focus on indeterminism, though. Thanks! I'll give it a look. It's probably good for playing around with to get a feel for it.
Re: D 2015/2016 Vision?
On 10/8/2015 4:15 AM, Ola Fosheim Grøstad wrote: I personally think that they future is with actor-based programming in combination with substructural/behavioural typing since it lends itself to distributed computing, multi core etc. I've recently become curious about the actor model and would like to learn more about it and maybe play around with it a bit. The C++ Actor Framework looks good, but unfortunately it doesn't yet work with MSVC so I'm waiting for that. The challenge is making a good language for it that is sufficiently performant and still allows breaking out actors to other computational units (computers/CPUs). I read a comment* on stack overflow that mentions that the important component is actually environment/platform such as OTP is for Erlang. I'm not sure how this affects the C++ actor implementations. *The last answer at: http://stackoverflow.com/questions/8107612/the-actor-model-why-is-erlang-special-or-why-do-you-need-another-language-for
Re: D 2015/2016 Vision?
On 10/8/2015 8:51 AM, Ola Fosheim Grøstad wrote: On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote: Yes, in general ownership should not be circular at all. It should be a DAG growing from the current actor/process/stack in an unbroken chain of ownership-references. +1. Reference counting has not been much of an issue for me since using smart pointers because I rarely if ever need std::shared_ptr. It's about ownership and std::unique_ptr works fine for that. (std::shared_ptr gets overused and shouldn't be a substitute for a GC). Parents can own a resource with std::unique_ptr and distribute access to it using native pointers. You just need to be aware of lifetimes. I guess people might consider that having to worry about lifetime management is a disadvantage but I have no problem with it.
Re: Shout out to D at cppcon, when talkign about ranges.
I haven't watched it yet, but it seems to be similar to this one from NWCPP I watched recently: https://www.youtube.com/watch?v=8yV2ONeWXyI
Re: Current state of GUI's
On 9/3/2015 10:51 AM, motaito wrote: And working in visual studio is really nice too. I wish there was a cross platform IDE like that. I don't quite like the text editor from eclipse, but I haven't used it in a while. Maybe I need to give it another try. Just in case you hadn't seen it, there is now Visual Studio Code: https://code.visualstudio.com/ Although I haven't really looked at it myself. I don't think it can accept plug-ins (yet) such as VisualD so that may rule it out.
Re: Current state of GUI's
On 9/3/2015 5:19 AM, motaito wrote: Hi, I haven't used D before and wanted to take a closer look at it. However, there are a few things that keep me from doing so. I'm in a similar place as you are. While D is better than C++, right now C++ plus JUCE is better for me overall than D plus . C# plus WPF seems attractive too except that WPF isn't cross platform. Anyway, I still always keep an eye on D.
Re: GC-proof resource classes
On 8/29/2015 8:20 AM, cym13 wrote: I think there should be a separation of concerns that isn't possible right now. Freeing ressources and freeing memory isn't the same thing and they should be decoupled. I think a destructor is there to free ressources, and the GC is there to free memory. If the GC doesn't call the destructor then why should having a destructor have anything to do with the GC? This. I think when language designers consider reference counting vs. garbage collection in the beginning, they decide that reference counting is too costly, particularly in cases where you may need to create many small objects. So garbage collection seems to make more sense if you have to choose one or the other. But the places I want deterministic destruction always tend to be when there are only one or a few objects because they are handles or wrappers for resources which aren't very numerous. So the cost of reference counting is negligible and is worth it in these cases. But unfortunately this problem got swept under the rug with garbage collection. I confess I haven't thought about this in depth and surely other people have; so there may be reasons why this is a more difficult problem than I think. But I agree there should be a separation of concerns between memory and other resources. But there may need to be some sort of transitivity with it, similar to const/immutable. That is, if I have an object which needs reference counting---for which the resources need to be cleaned up---and it is a member of another object, then the owning object also needs to be reference counted automatically or made to be a compiler error. Whether this is implicit just by having a destructor defined or explicit I'm not sure. I just don't know if this could be handled at all with collection classes. (How would they know?) Does it make sense that this needs to be tied to structs and not classes? I'm not a language designer so I don't know the reasons. But ideally I'd think the whole concern of releasing resources would also be separate from that as well. Regarding the garbage collector, if the destructor isn't guaranteed to be called, then I have to assume the worst case that it won't be called. That means I should not use destructors in these cases. It seems to me that should be enough argument.
Re: RAII and Deterministic Destruction
Thanks for the thorough response. I'm aware of some of what you explained. Maybe I should have asked differently. Rather than asking what RAII facilities do exist, I guess I was looking for the answer, Here's what you typically do in C++ RAII that you can't do in D. I could probably find out things by experimenting too (and not be too lazy). I just didn't want to rely on my assumptions only. For example, say object A is a member of object B which is in turn a member of object C. If C is deleted or goes out of scope, does the destructor of A get called? If all three are classes, obviously not. But if all three are structs? What if they are classes but are all managed by Unique? If I use Unique for all of my heap-allocated classes (as I would with std::unique_ptr in C++) am I assured of destructors being called when the owning classes get destructed? I'm wondering about these various nesting/owning combinations. Jim
Re: RAII and Deterministic Destruction
Thanks. I had not looked at some of those yet. Jim
Re: RAII and Deterministic Destruction
Thanks for all the info. It's a good comparison of structs and classes to keep handy. Actually, I'm fine with the GC. I don't mean to avoid it. I just would like some way to also have non-memory resources automatically released in a timely, predictable way. One common thing to do in C++ is to manage the lifetime of an object with std::unique_ptr but then use its .get() function to get a native pointer to use temporarily. You just have to ensure that the native pointer doesn't outlive the unique_ptr, which isn't that difficult. True, if the unique_ptr gets destructed the native pointer is invalid and that could be risky, but you limit its use. Unique in D doesn't seem to have anything like a get() function but I wonder if it could. That is, it would get another native reference to the Unique resource that is managed by the garbage collector. So if the Unique went out of scope and got destructed, the reference would at least refer to valid memory although not a valid object because its destructor had already been called. Not perfectly safe, but no worse than the C++ case. Just a thought. Jim
RAII and Deterministic Destruction
Although C++ can be ugly, one reason I keep going back to it rather then commit more time to reference-based languages like C# is because I like deterministic destruction so much. My question is whether D can REALLY handle this or not. I've not been sure about this for some time so now I'm just going to come out and finally ask. I know about this RAII section in the documentation: http://dlang.org/cpptod.html#raii But I don't believe that handles all cases, such as having classes as member variables of other classes. (Do the members get destructors called too?) Then there is std.typecons.Unique and std.typecons.RefCounted. With these, can I really get deterministic destruction for all cases like I would in C++? If so, it might be a good idea to emphasize this more in the documentation because I'd think people coming from C++ would be looking for this. Jim
Re: Announcing dplug, a toolkit for making audio plugins with D
On 6/13/2015 7:18 AM, ponce wrote: dplug is a library for audio plugin development. https://github.com/p0nce/dplug http://code.dlang.org/packages/dplug It's aim is to be a lean alternative to JUCE and IPlug, the most used C++ libraries in this space. It is currently less useful since supporting only VST 2.x on Windows. The plan is to gradually add more formats and OS support (VST Mac and AudioUnit should be first). Because of the particular need of audio plugins (lazy screen updates, message dispatch made by host, threading, child window...), dplug has its own windowing. It then use a deffered software renderer to have a nice procedural UI and keep installer sizes low. This is a nice announcement to me since I'm a user of JUCE. Is this meant to by only for creating plug-ins or can the audio interface be used outside of a plug-in? A cross-platform MIDI library would also be a cool thing. Pardon my ignorance if there already is one for D I wasn't aware of.
Re: What Features Should A GUI toolkit have?
I'd like to see D with GUI framework like JUCE. That's what would make me use D more. For now I'll stick with C++ and JUCE. I know it sounds superficial to have your choice of language based so much on GUI, but I write software for average people to use, not for other programmers (and not for servers). Average people use GUIs. I like with JUCE how it's very easy to make your own UI elements when you need to by using drawing primitives inside a paint() function. Then you can apply transforms to zoom in/out or manipulate easily.
Re: What Programming Book Should I Read Next?
On 7/26/2014 5:58 PM, H. S. Teoh via Digitalmars-d wrote: I've to say, that learning D and contributing to D has greatly expanded my programming horizons. I've been doing C/C++ for about 2 decades, and about 8 years ago I felt I'd started to taper off in terms of learning new things in programming. Until I found D, that is. D made hard / complex things in C++ easy, and opened up new horizons -- like weak purity, range-based component programming, new possibilities in metaprogramming, etc.. Contributing to Phobos was also quite eye-opening in learning about novel ways of handling common tasks in a standard library. I daresay I learned more contributing to Phobos than from my full-time job (mainly C with some C++ and a smattering of Javascript, PHP, and some other stuff). T Sorry if this is too off-topic, please tell me if so. As I read the D newsgroup I notice that a lot of you guys who are really quite knowledgeable about languages are doing things like C programming as a day job. I recently (like 2 weeks ago) resigned my current job of over 10 years. One of the reasons is that the work has veered too far from why I got into this career in the first place. The code for the product, in C++, has been largely finished (by me) so the only coding I do is small modifications to it. Mostly what I do now is what follows that: customizations for OEM customers, Windows installers, rebuilding the product, testing, testing, certification testing. There are more issues, but I'll spare you :-). I do try to learn more about things like Haskell and D and meta-programming and ranges, etc., but there isn't so much time when your regular job takes up over 40 hours a week. With programming, I feel like you can read about something but you can't really be proficient at it until you use it hands-on and practice it regularly. So I think it helps to try to find a job where you can do some of that during work time. I hope to do that. But then I read here where a lot of you guys have day jobs not even doing C++ but C programming, I feel like some of you are in the same boat, and more so because you're more knowledgeable than me. So how do you feel about that? Jim
Re: DlangUI
Very nice, thanks. I'm looking forward to trying it out when I can find the time. I'm not a big fan of bindings/wrappers. Jim
Re: Signals far from Slots
Thanks Ali, In the second part of that example I was hoping it was understood that Bar generates it's own signal. Sorry, I guess I wasn't clear; I was just trying to reduce code. I think maybe I'm really looking for a way that BarContainer doesn't have to know that Bar and Foo are connected. One way I used to do this was to have a central EventManager object that all other objects knew about and it would be the traffic cop for events. So you have the traditional Java type of Observer implementation and then listeners register with the EventManager saying that they are interested in a type of event while signalers send all their events to the EventManager. Since signals and slots are intended to have some advantage over the Java way, I wondered if there was a better way to handle the setting up of the connection. (Signals and slots decreases coupling of objects, but then some controller object needs to know about them enough to connect them.) Sorry, maybe this is the wrong place to ask such questions. I know there are plenty of forums for specific languages and APIs. But I don't know of any that just deal with general design, which is what I'd like to get better at. BTW, thanks for your D tutorial! It's a big help to me. Jim
Signals far from Slots
Is there a good way to connect signals and slots when the objects are
far apart? All tutorials for signals and slots show the objects being
readily accessible by the main() function. But what if they're not? Is
there an elegant design?
For example, here's a typical minimal demo:
-
class Foo
{
void Listen()
{
writeln(Foo: I hear you!);
}
}
class Bar
{
mixin Signal!() barSignal;
void SaySomething()
{emit(); }
}
int main(string[] argv)
{
Foo f = new Foo();
Bar b = new Bar();
b.barSignal.connect(f.Listen);
b.SaySomething();
return 0;
}
---
The main() function is a kind of controller that connects up the
components. But let's say main() doesn't have access to Bar because it's
behind a layer:
--
class BarContainer
{
this() { b = new Bar(); }
void SetBarSignalHandler(b.barSignal.slot_t dg)
{b.barSignal.connect(dg); }
private Bar b;
};
int main(string[] argv)
{
Foo f = new Foo();
BarContainer bc = new BarContainer();
bc.SetBarSignalHandler(f.Listen);
return 0;
}
--
This can get worse if there is also a FooContainer and objects get
further away.
My first thought is to pass the delegates through the layers, as in the
SetBarSignalHandler() function in BarContainer. But this seems kind of
ugly as all the layers need to know about the connection between the
signaling object and the observer object. It would be nice if they
didn't have to.
Do you know any any cleaner way?
Jim
