Re: Linus with some good observations on garbage collection
This sort of reference count with cyclic dependency detector is how a lot of scripting languages do it, or did it in the past. The problem was that lazy generational GCs are believed to have better throughput in general. I'd like to say "were proved" rather than "are believed", but I don't actually know where to go for such evidence. However, I do believe many scripting languages, such as python, eventually ditched the reference counting technique for generational, and Java has very fast GC, so I am inclined to believe those real-life solutions than Linus. Mike On Fri, Apr 22, 2011 at 2:32 PM, Alvaro wrote: > El 22/04/2011 19:36, Walter Bright escribió: > > http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html >> > > I've always been surprised when discussions usually just bring garbage > collection as the only alternative to explicit manual memory management. I > imagined it as a garbage truck that has its own schedule and may let a lot > of trash pile up before passing by. I always naively thought, why not just > free immediately when an object gets no references? > > Not an expert, so there may be reasons I don't see, but now that Linus says > somethnig along the lines, I'll ask. Why not? Isn't it much easier to do > refcount++ and refcount--, and if refcount==0 immediately "free()"? Memory > will be available to other needs faster, no need for an additional thread, > or a lot of memory consumed before the advanced garbage truck decides to > come in, or slight pauses when collecting trash (maybe only in old > implementations), and the implementation is much simpler... > > OK, I knew about that "cyclic references" problem. But Linus doesn't seem > to see a big problem and solutions can be found with care... >
Re: emscripten
On Thu, Dec 16, 2010 at 2:48 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1046.1292468790.21107.digitalmar...@puremagic.com... > >> there's no integration with the > > external environment > > > > But it is an advantage at the same time as it's a weakness. The > advantage > > is, I can read and use gmail or google docs anywhere, firewall or not. > > > > That's entirely possible without cramming the whole thing through a > webpage. > I can thank of at least a couple ways just off the top of my head. The > *only* reason you don't see outside of the web browser it is because > everyone making "use-anywhere" apps is insisting doing it through the web > browser. It's *not* a technical limitation of not using a web browser. If > anything, it's just a widespread misconception amoung people who grew up > writing web code and therefore don't know any better about what is and > isn't > possible. > What's possible and what's reasonable to two are different things. Clearly, implementors and users are converging on the idea that browsers are the easiest way to do this. You can do it other ways, go ahead. You think you'll get widespread adoption? You can argue against javascript and browsers, sure, but I'm not sure why you feel it's productive to be so insulting about it.
Re: emscripten
On Thu, Dec 16, 2010 at 2:22 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1053.1292506694.21107.digitalmar...@puremagic.com... > > > > And CAPTCHAs prove that javascript and browsers are terrible??? > > > > Where are you gettng that? That's not even remotely what he said. He was > clearly saying that CAPTCHAs and registration are a counter-argument to the > notion that most webapps are zero-config. Or at least that they're not > really much better than having to do some basic config. > > The conversation was about technologies, not specific webapps. The emotional outburst that began this aspect of the discussion was that javascript sucks, period, end of story, without any possibility of ever being otherwise. CAPTCHAs are irrelevant.
Re: emscripten
And CAPTCHAs prove that javascript and browsers are terrible??? You must have failed logic class. Probably you never took it, knowing how poorly you would do. I should criticize your precious local apps because some require dongles. On Thu, Dec 16, 2010 at 8:28 AM, Adam Ruppe wrote: > Andrew Wiley wrote: > > Web applications have zero-install > > But they trade it in for registration, with those awful, awful > CAPTCHAs. > > They don't just distinguish between humans and computers (sometimes). > They also distinguish between flawless humans with perfect vision > and expensive monitors and real life humans who can't see the > poorly contrasting colors or can't distinguish letters with a > font size of 8 pixels. Some have letters right on top of each > other what order do they want it? Gah. > > It invariably takes me two or three attempts to get those stupid > things. Thankfully, the popular Re-Captcha ones are among the > easiest to read, but that doesn't help when someone still uses > the green on red with purple stripes and tiny font variety. It's > been a while since I saw the Google captcha, but I remember it > as being nearly impossible. > > > The worst part is they come back post-registration too! Vile. >
Re: emscripten
> there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. I could sit here at home, open an openoffice doc, write in it, save it. Then tomorrow go to work, open open office and bitch and scream about why the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I *LOATHE* Open Office! I can't do the simplest thing! But, no, I recognize the limitations of the different mediums, and rather than look at what is not exactly the same as what I'm used to, I can see what it does that I've not been able to do before. If you'd asked me 1 year ago about javascript, I would have laughed and said no way I would want to use that crap. I've learned to think otherwise since. If you go looking for problems, you're going to find them. To me, it simply indicates inflexibility on your part. Which is fine, like I said, the world doesn't care about your inability to adapt and see new possibilities. It's just, the strength of the emotional response in this thread has been kind of revealing. Mike On Wed, Dec 15, 2010 at 9:20 PM, Adam D. Ruppe wrote: > > So much hate because you can't middle-click paste. > > It's illustrative of a bigger overall problem: there's no integration with > the > external environment; no use of native capabilities, ignoring user system > setups, > and not even integration with other web apps. With a Windows program, you > can set > up a user theme. Well behaved programs will honor your colors, layouts, > etc. > > One of the reasons I stick to my old Konqueror is it uses the website icon > and > title in my system taskbar and tries to honor my user settings. Most > browsers > don't even try that, but even with konq, the integration is quite poor. > > While web apps could, in theory, get some consistency with user defined > stylesheets, in practice, this would just break sites, since they are all > so > accustomed to being independent. > > It's just like DOS. Except DOS apps could actually /use/ the hardware > available to > them... >
Re: emscripten
So much hate because you can't middle-click paste. Swearing and AAAggghhing, "loathing", etc. It's childish and hard to take such attitudes seriously. The world moves on and doesn't care that you can't adapt to the simplest of things. On Wed, Dec 15, 2010 at 5:20 PM, Adam D. Ruppe wrote: > Tangentially related to this thread. I just went back to my work to-do > list, which > the rest of the team puts up on a Google Doc. > > I *loathe* Google Docs, for a lot of reasons. But one more: my X11 > selection > doesn't work. This is with Firefox 3.6. > > In Linux, with most programs, you can select text, then middle click in a > text > input box to instantly paste it. This includes standard html text in the > web browsers. > > ... but not Google Docs text. It highlights in a weird looking color, not > matching > the rest of my system. It lags as I drag or scroll. And it doesn't update > the X > selection, so when I middle click out of habit... the wrong thing happens. > arrg! > > > Those javascript things never pay attention to details, and even those that > do > don't know the quirks of platforms or individual user setup, and even if > they do > know, there's nothing they can do about it! > > > Now, if they just output a standard html document, these details would be > handled > properly. Firefox itself knows it is a Linux program, has access to the > Linux > APIs, and manages them somewhat well. > > Or if it was a standard doc, I could open it in my other browser and maybe > it'd do > a better job. > > But nope, open it in my no-script Konqueror 3.5, and it just says > > === > Google Docs is not supported in your browser. Learn more Dismiss > === > > And a blank screen under it. I can't even view the text, despite it being > just > text. Fucking garbage. >
Re: emscripten
>With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. But what about your group-think lemming mother? On Wed, Dec 15, 2010 at 3:36 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com... > > On Wed, Dec 15, 2010 at 2:26 PM, retard wrote: > > > >> Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote: > >> > >> > The point was that while Javascript is slow, it's getting fast enough > >> > to be useful. Yes, it's not C. It will never be. But the fact that any > >> > sort of realtime calculations are possible in it is a breakthrough > that > >> > will be reflected in actual application code. Javascript was not > >> > designed to be fast, and honestly, it doesn't need to be fast to fill > >> > it's niche. > >> > >> I'm not getting this. WHY we should use Javascript/HTML5 applications > >> instead. I'm perfectly happy with my existing tools. They work nicely. > It > >> takes years to develop these applications on top of HTML5. I simply have > >> no motivation to use web applications. They have several downsides: > >> > >> - you "rent" the app, you don't "own" it anymore > >> > > > > Many would find that a benefit, as updates are automatic, never need to > > install new versions. > > > > It's not uncommon for newer versions to be worse. Look at Acrobat Reader, > iTunes, and Nero. A lot of people don't want to be forced into updates that > make things worse. My Mom uses Hotmail and has a fit every time they decide > to change everything around (which seems to be quite a lot). She'd be far > happier with something that didn't work that way, but she sticks with it > because she's every bit as much of a group-think lemming as everyone else. > > > > > >> => which leads to: advertisements, monthly fees > >> > > > > Again, benefits galore for some folks. Should I pay $80 to buy the > > software > > and find out if I like it, and another $40 two years later to upgrade, or > > pay $4/month and quit whenever I'm done with it? > > > > Or get freeware/FLOSS and pay nothing and have no ads. And there's > ad-supported desktop software too, so with desktop software you can go > either way. Web apps can't go either way, because there's always the > possibility the owner will pull the plug, and even if they don't, the > ownser > will still have server expenses which will have to get paid somehow. > > >> > >> - worse privacy (do I want some Mark SuckerBerg to spy on my personal > >> life for personal gain) > >> > > > > Same issues with applications you install on your computer. Perhaps they > > are worse in that case, since so many people have so many problems with > > malware, spyware, worms and viruses. > > > > With my own computer, there are things I can do to prevent that. With > webapps I'm 100% reliant on someone else: there isn't a damn thing I can > do. > > >> > >> - worse security (a networkless local box IS quite safe, if CIA is > >> raiding your house every week, you're probably doing something wrong, > >> otherwise, buy better locks) > >> > > > > Javascript+browser can be a purely client-machine application too just > > like > > D or Java or C > > > > Yes, but what would be the point? It would be all downsides and no upsides. > If you're going to have a local app it may as well be > D/Java/C/Python/whatever. > > >> > >> - worse performance (at least now and in the next few years) > >> > > > > Yes. But if you take frame rates in games, which is a terrible example > > for > > javascript, the more general truth is that beyond a certain point, > > performance differences are undetectable to the human eye. > > Which the vast majority of JS web apps are nowhere remotely near. > > > At which point, > > the only thing driving your technology choice is developer productivity. > > Which once again is a big vote *against* web-browser-as-a-platform. > > >> > >> - worse usability > >> > > > > Completely disagree. Desktop apps right now have an enormous advantage > in > > how much development-hours have gone into them over web app counterparts. > > This will change, quickly. > > > > I've been hearing that for a long time. Still waiting. In the meantime, the > only changes I've seen have been for the worse. > > >> > >> I know the good sides. No need to mention them. In my opinion the > >> downsides are still more important when making the decision. > >> > > > > Honestly, where do think things will stand 5-10 years from now? > > > > I shudder to even think...Nowhere good considering the directions things > are > moving. > > > >
Re: emscripten
Do you complain that Excel doesn't not "degrade gracefully"? Why would someone even think to load the app in lynx? Do you load excel files in lynx? On Wed, Dec 15, 2010 at 3:32 PM, Adam D. Ruppe wrote: > Michael Stover wrote: > > If I provide a spreadsheet program via javascript, > > why should it have to work in Lynx? > > It doesn't necessarily have to work, but it should degrade gracefully. If > it goes > all the way down the Lynx gracefully, that means it is most likely usable > by everyone. > > For a spreadsheet, I'd output the data in an html table. Now all users can > at > least view the saved document, with no extra effort from you. >
Re: emscripten
>Trying to make an online payment to Visa or check on one of Visa's policies? Are you gonna be able to do that at MasterCard's website? With desktop software stuff like that rarely happens. Basically, websites/webapps have a greater need for compatibility than desktop apps do. Again, we're not talking about *websites*. We're talking about web *apps*. Of course your bank site ought to provide you your account info whether you are on a Mac or Windows and even if you use IE 5.5. But that's not what we're talking about. We're talking about someone making an application that, today or in the past you would have downloaded and installed, and instead making it runnable in a browser. It's not content, it's *behavior*you're there for, and therefore, if they require Chrome and you are a devoted Firefox user, then you can find someone else who provides that behavior in Firefox and use them instead. There's no tie to some particular content provided (like Visa), just like there isn't with desktop apps. Mike On Wed, Dec 15, 2010 at 3:14 PM, Nick Sabalausky wrote: > "David Nadlinger" wrote in message > news:ieb3q0$1n...@digitalmars.com... > > On 12/15/10 8:04 PM, Nick Sabalausky wrote: > >> Are they in 99.9% of the browsers *actually being used now*? > > > > As it was already discussed, this is not as much of an argument as it > > might seem - Windows x86 isn't used on 99.9% of all machines either. > > > > First of all, the percentage of user machines that are Windows is much much > higher than the percentage of browsers being used that are bleeding-edge. > > Secondly, If someones going to make a non-cross-platform desktop app these > days, I'd consider that silly too. Maybe less silly, but only because it's > notably easier to test a page with JS on/off and in multiple browsers than > to test an app on multiple OSes, and because there is Wine. > > Third, it's uncommon to need to use a *specific* non-cross-platform app. > The > vast majority of the time there are alternates available. But it's not > uncommon at all for a website to not have an alternate equivalent. Trying > to > make an online payment to Visa or check on one of Visa's policies? Are you > gonna be able to do that at MasterCard's website? With desktop software > stuff like that rarely happens. Basically, websites/webapps have a greater > need for compatibility than desktop apps do. > > > >
Re: emscripten
If I provide a spreadsheet program via javascript, why should it have to work in Lynx? It's not a web page. I'm providing absolutely ZERO content. It is only behavior, just like Excel is only behavior. If I provide the same functionality, but only if you use Chrome or Firefox, why is that so horrible? On Wed, Dec 15, 2010 at 2:50 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1034.1292441124.21107.digitalmar...@puremagic.com... > > >And no, I'm *not* playing semantics games here: "Distributed via the > > web" means exactly what it means > > > > Of course you're playing semantic games. Not being very helpful in the > > discussion. You seem to be arguing that if the content arrived via > "http" > > it must work in lynx or else it "sucks". > > > > Not at all. In fact that blatantly contradicts what I just pointed out. > Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever, > like that matters) and yet, like I said, they're obviously not what we're > talking about when we're talking about web apps. > > Secondly, I'm not the one that brought up Lynx. Although if there's > something that clearly doesn't need graphics and such to be useful, then > yes, it absolutely should work on Lynx. Apps obviously shouldn't require > things they don't need: My DB shouldn't require I have a webcam installed. > Grep shouldn't require an email client. Making a backup shouldn't require > OpenGL or a printer. Submitting a form or downloading a PDF shouldn't > require JS or HTML images. Viewing information on an official county > probate > court website shouldn't require Flash (I've actually seen that, and I'd be > very surprised if it doesn't violate multiple government-mandated > accessibility requirements). Etc. > > >
Re: emscripten
On Wed, Dec 15, 2010 at 2:26 PM, retard wrote: > Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote: > > > The point was that while Javascript is slow, it's getting fast enough > > to be useful. Yes, it's not C. It will never be. But the fact that any > > sort of realtime calculations are possible in it is a breakthrough that > > will be reflected in actual application code. Javascript was not > > designed to be fast, and honestly, it doesn't need to be fast to fill > > it's niche. > > I'm not getting this. WHY we should use Javascript/HTML5 applications > instead. I'm perfectly happy with my existing tools. They work nicely. It > takes years to develop these applications on top of HTML5. I simply have > no motivation to use web applications. They have several downsides: > > - you "rent" the app, you don't "own" it anymore > Many would find that a benefit, as updates are automatic, never need to install new versions. > => which leads to: advertisements, monthly fees > Again, benefits galore for some folks. Should I pay $80 to buy the software and find out if I like it, and another $40 two years later to upgrade, or pay $4/month and quit whenever I'm done with it? - this is especially bad if you're already using free as in beer/ > speech software > gmail is free as in beer and nothing prevents it being open source. > - this is especially bad ethically if you're writing free software > There is no change here. > > - worse privacy (do I want some Mark SuckerBerg to spy on my personal > life for personal gain) > Same issues with applications you install on your computer. Perhaps they are worse in that case, since so many people have so many problems with malware, spyware, worms and viruses. > > - worse security (a networkless local box IS quite safe, if CIA is > raiding your house every week, you're probably doing something wrong, > otherwise, buy better locks) > Javascript+browser can be a purely client-machine application too just like D or Java or C > > - worse performance (at least now and in the next few years) > Yes. But if you take frame rates in games, which is a terrible example for javascript, the more general truth is that beyond a certain point, performance differences are undetectable to the human eye. At which point, the only thing driving your technology choice is developer productivity. Even before that point of undetectability, most people will choose the app that provides more features over the one that performs somewhat better. And for good reason. Something being a little slow vs not being able to do it at all is an easy choice for most people. People on this mailing list are somewhat eccentric in their demands, which is entirely their right, but y'all should at least recognize web apps are and will be successful by and large. > > - worse usability > Completely disagree. Desktop apps right now have an enormous advantage in how much development-hours have gone into them over web app counterparts. This will change, quickly. > > - worse reliability (network problems, server problems) > In theory, yes, and once in a while it is a problem, but I honestly can't remember the last time I had any issues with connectivity. > > I know the good sides. No need to mention them. In my opinion the > downsides are still more important when making the decision. > Honestly, where do think things will stand 5-10 years from now?
Re: emscripten
>And no, I'm *not* playing semantics games here: "Distributed via the web" means exactly what it means Of course you're playing semantic games. Not being very helpful in the discussion. You seem to be arguing that if the content arrived via "http" it must work in lynx or else it "sucks". Perhaps I will just rename it to "ws" and then you can have some new expectations that don't cloud your judgement so. On Wed, Dec 15, 2010 at 1:51 PM, Adam D. Ruppe wrote: > Nick Sabalausky wrote: > > that's *proof* of how horrid JS is > > I often feel Google is re-discovering DOS' capabilities and going on about > how > great it is. Got it in graphics and input, and files too. > > HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a > filesystem > with only a root directory! > > I wonder if it even works to store interesting data. When I was working on > the > DWS/AJAX viewer (Which I still intend to finish if I get a decent break > from > work... that I don't spend flamewarring on the newsgroup), I tried to get a > binary > string sent down, manipulated, and finally displayed as an image. > > But: > > var img = new Image(binaryData); // didn't work > > Some browsers supported a img.src = "data://" + encodedBinaryData, but not > all of > them did, and the limit was obscenely small anyway. > > I ultimately just served it from the server and referenced it via url. But > I had > that option since there was a server app available... what would the local > storage do? > > > Blargh. > > > > I'm sure as hell not going to be one of > > those "This site best viewed with X browser" assholes. > > I might be one of those people, though I don't come out and say it, my > sites do > tend to be best viewed with X browser. > > But the important difference is it still *works* in Y and Z browser. It > just won't > have rounded corners, etc. >
Re: emscripten
All of your complaints are about specific choices of the developers, not the technology. Right now, javascript and web apps are being written (for the most part) by young, inexperienced, often graphically-oriented individuals. Soon, more experience developers will join the scene and start writing useful apps that aren't just eye-candy. >Any my emails are *my* emails, stored on my local box. If I want to back it up, just copy the file. If I want a search that actually works, I can just grep the file, and so on. Just better in every way. The vast majority of people appreciate that they just get all that for free and without bother in gmail, hotmail, yahoo, etc. -Mike On Wed, Dec 15, 2010 at 9:47 AM, Adam D. Ruppe wrote: > Nick Sabalausky wrote: > > Text editors that rely on JavaScript are abominations, period. > > Any widget that does sucks IMO. I've had to use javascript replacements of > the > standard tag too, and wow it blows. > > Wait for its animation to start up. Wait for its animation to finish. Click > an > option it didn't work, sorry my browser isn't good enough. > > Usually I just abandon the site, but sometimes I can't. So switch to > firefox 3. > Wait for the animation to start up. Wait for it to finish. Click the thing. > Wait > for it to animate again. Oops, I got the wrong option, I'll just hit the > down > arrow sorry, didn't work. > > Aargghh! > > "but but look at the super cool animations jquery is amazing! and i can > style this > thing better than the built in so nyah" > > Gah. > > > > Look, look -> There's my cake, and I'm eating it! > > This is one thing I love about running mutt in screen. If I have access to > my home > box at all (directly or ssh) it works well. If I left a message half read, > when I > come back to it, it is still half read! No need to hunt it down again among > the > read messages, no need to scroll back to my original position. The screen > is > *exactly* as I left it. > > Any my emails are *my* emails, stored on my local box. If I want to back it > up, > just copy the file. If I want a search that actually works, I can just grep > the > file, and so on. Just better in every way. >
Re: emscripten
And that's the problem - we're talking about applications that happen to be distributed via the web, not a "website". Everyone's demands that it work in lynx, FF2, with javascript turned off, etc are ludicrous. You don't get to make such demands of applications. Some applications are Windows only. Some don't follow platform standards. Some require 1GB to work effectively. None let you require it work without running code, etc. These expectations are invalid. On Wed, Dec 15, 2010 at 2:24 AM, Nick Sabalausky wrote: > "Adam D. Ruppe" wrote in message > news:ie9hjv$r1...@digitalmars.com... > >> What about Hotmail, Yahoo, MobileMe, etc? > > > > I haven't used most of them for a long time. Gmail gets most > > my ranting because its the one I've used most recently. (And > > I remember my password to it so I could sign in and re-check > > my statements before posting too.) > > > > If I were writing a webmail program, here's how I'd do it though: > > > > 1) Start with a regular HTML view. A simple table of from/date/ > > subject, and a compose button. The messages are standard links, so > opening > > in a > > new window works as expected. > > > > The compose screen is a very basic form. The website should be > > perfectly usable in the Lynx browser. > > > > 2) Beef up the html. Ensure things like accesskeys and tabindexes are > set, > > so > > keyboard control works at least somewhat well. > > > > 3) Go back and start adding stuff on to it with scripts. The gmail > polling > > for new > > message notification is pretty useful, so add that. Having > auto-completion > > of your > > friends' email addresses is a nice thing gmail does too. I might add a > > document > > keypress handler to add hotkeys, since I'm not really happy with browser > > implementations of accesskeys (alt+shift+letter in firefox - did they not > > realize > > the whole point was to be /accessible/? I can't get my fingers to contort > > that way > > without hunt+pecking with both hands! But my old konqueror is much > > better - hit > > control to toggle them on and off - and that's what I use, so meh.) > > > > 4) The scripts might fetch the message after the one you click on as > well, > > just > > ajax getting the next document in line then doing nothing with the > result. > > My > > server code would be configured to send the proper cache headers, meaning > > when you > > click the link to actually view it, it is pre-loaded in the cache, and > > thus loads > > instantly. A lot of websites do it for images, why not documents too? > This > > would > > keep the user visible latency to a minimum while browsing messages. > > > > > > That's about it. It wouldn't be as good as a real application, but it'd > be > > good > > enough as webmail with or without scripting. > > You've just described what I call "The *right* way to make a website". > > >
Re: emscripten
I've used Pegasus, thunderbird, Exchange, Evolution, and whatever is on my Mac by default (briefly). I've used other web emails too, including one for Exchange, which is terrible. Some of your complaints are not generic to javascript/web apps - like the right click complaint. It can be done easily. They didn't do it, but this complaint is not damning against the browser platform. Complaining the editor isn't like vi just makes me roll my eyes. Few would really want it to be. However, again, there are vi clones in javascript, if one were really wanted it. I didn't understand your complaint about having to read one thread at a time. I don't have the ability to read more than one at a time anyway, so I do not have this complaint. The server has never been slow for me, at all. I set one browser tab to gmail at the start of the day and never think about it again. New emails are always just there for me. I can go anywhere and get my email, including the computers at the Y, the library, from behind the firewall at work, and on my sister's computer when I go visit her for Christmas. I won't have to install anything to be able to do so. I probably get ~100 non-spam emails a day here. Managing it is hardly any work at all. I really don't think the complaints about the browser platform and javascript have much validity anymore. They used to. But I think those days are gone, and I think it's like the whole "java is slow" phenomenon. It takes a ridiculously long time for most people to change their perception of things once they've had a bad experience. Mike On Tue, Dec 14, 2010 at 7:15 PM, Adam D. Ruppe wrote: > > I don't have any problems you seem to have with gmail. > > Two questions: > > a) Have you ever tried a better alternative? If you've only > used crap, a polished turd looks really really good. > > b) How much email do you handle? I used the web interface > for quite a while before I went into business. It works ok > if you do a low volume of low priority email stuff. (as they > say, anything is fast with small n) > > I just logged in. Here's what it greeted me with (after taking > its sweet time loading): > > Inbox (31187) > > Though now, even for a small volume, I can't go back. It'd be > like using C after spending so much time with D. >
Re: emscripten
I don't have any problems you seem to have with gmail. I suspect attitude is a big difference. On Tue, Dec 14, 2010 at 6:43 PM, Adam D. Ruppe wrote: > Michael Stover: > > Did you use the gmail webapp to write that? > > No. My public email address is gmail so I get a free spam > filter and online archive, but I don't actually use their > awful, awful interface. (All incoming mail to that address is > forwarded to my real email address, and my outgoing mail is > SMTP relayed back through gmail. My real address remains spam > free by being secret.) > > This does bring me to two rants though: > > a) Gmail's web interface is horrible, even the basic HTML > version. Consider this: right click a message... no "open in > new window" option! WTF. > > I handle, on average, about 170 emails a day. In my mail client > (mutt) and my server setup, this is no bother for me. There's no > waiting on slow servers. The controls are natural and fluid. I can > pick up on another computer right where I left off, thanks to > GNU screen. When I'm emailed a dozen attachments, it is a simple > case of hitting a button to save them all locally - no annoying > scan and downloading of them individually. > > With gmail, I'd have to click through the messages one thread at a time, > never > seeing the whole message (their hiding of quoted text and signatures, not > 100% > accurate!). Try to reply? Have to deal > with their godawful editor (with mutt I can just use vim) and > the hidden text below it (implicit top quoting, are they on drugs?). > > With new incoming mail, my computer beeps the second it arrives > and is idle while waiting. With gmail, it'd be sitting there > polling, at the notice it does give doesn't even compare in terms > of usability or speed. > > Oh, and search? Surely Google could get search right? Nope > > > The worst part? Gmail might have the best of the web mail interfaces. Goes > to tell > you how dreadfully awful they are in general. > > > > b) I am posting this from the digitalmars news web interface. > For some reason, my emails don't seem to reliably get through. > > And this php webnews thing makes gmail look like heaven. It's > amazing the level of suck in this thing. I'm sure everyone > who has used it will agree so I'll spare you the long rant. > > But there's times that I feel the greatest service someone > could do for D would be to replace this thing! >
Re: emscripten
On Tue, Dec 14, 2010 at 2:03 PM, Adam Ruppe wrote: > > Have you tried, for example, CoffeeScript: > > I have not - my main problem with Javascript isn't so much the > language as the browsers in which it runs, which is why I feel things > like emscripten (and google native client) are pretty useless. > > Browsers are good for displaying html pages. Javascript is good > for enhancing those html pages. But they aren't very good at full > blown applications. > Adam Ruppe Did you use the gmail webapp to write that? > I do have a list of flames against javascript the language too, > but none of them are huge in context. > > > Anyway looking at the coffeescript website... it looks like my worst > nightmare: something inspired by a mixing of Python and Ruby! I > don't think I could handle that. >
Re: emscripten
Facebook is hardly a fair example - they are not a true webapp and are more interested in numbers of users than quality of their app. Someone who was serious about making an application over the web would simply require Chrome or Firefox, and then 99% of your incompatibility issues go away, as well as your performance problems. Something like http://muro.deviantart.com/ is great and, to me, demonstrates the browser/javascript platform is more than capable. -Mike On Tue, Dec 14, 2010 at 10:49 AM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 12/14/10 9:25 AM, Sean Kelly wrote: > >> Adam Ruppe Wrote: >> >>> >>> Client side scripting sucks. It's garbage. Slow, incompatible, >>> unreliable, and a >>> piece of junk platform in general - it does very little that's >>> interesting. That's >>> not even getting into the language itself. >>> >> >> It totally sucks, but it does scale better than executing everything >> server-side. >> > > Surprisingly, it doesn't. Facebook is reducing its client-side Javascript > to a minimum in favor of server-side code. Reason? Speed. You can't control > user's OS, browser, and hardware platform, but you can control your own. > > Andrei >
Re: Why Ruby?
> > LOL. I'd _love_ to use D at work, but so much of our code is in C++ and > must compile with Visual Studio that the fact that C++ doesn't integrate with D all that well and the fact that you have to use dmc on Windows for the C or C++ code if you want to link it with D code make it so that it doesn't make any sense at all to use D at this point. Having to use the dmc compiler on windows in order to leverage legacy C++ code while being able to move on with new D code doesn't sound like too much of a restriction. Is there a similar tool that allows linking D and C++ on linux and mac? Mike On Sat, Dec 11, 2010 at 3:32 AM, Jonathan M Davis wrote: > On Saturday 11 December 2010 00:01:35 Andrei Alexandrescu wrote: > > On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote: > > > On 12/10/10 19:26, Ary Borenszweig wrote: > > >> http://vimeo.com/17420638 > > >> > > >> A very interesting talk. > > >> > > >> I used to like D. To write code in a high level while at the same > > >> time being very close to the machine, with class invariants, unit > > >> tests and many other features seemed very appealing. But I always > > >> felt there was something wrong. > > >> > > >> About a year ago I met Ruby. Now I find languages like Java, C#, > > >> Python and D kind of ugly and uncomfortable. Why? Exactly because of > > >> what it is said in that video. > > >> > > >> This is not to start a flame war or trolling, it's just to show you > > >> why I changed my mind so much about D, and why I think (IMHO) you > > >> should care about naming conventions (like bearophile says), more > > >> powerful unittests (and not having unittests integrated into the > > >> language but rather being able to build your own test frameworks > > >> with ease) and stop caring about being C-syntax friendly. The world > > >> doesn't need that many semicolons and parenthesis. :-) > > > > > > I'm a strange one. I use Ruby, and D. (And a couple of others...) I > > > use the tool that feels best for the job, whatever that may be at a > > > given time. Sitting on a disc somewhere are some personal tools I used > > > to use when working with D... which are themselves written in Ruby (and > > > bash script, but hey). > > > > > > Then again, I'm the same one who really really likes Ruby on Rails... > > > and yet still does most things with PHP. Why? Well for one, because > > > for plenty of projects, Rails is less an aid and more a hindrance. > (And > > > yes, before someone brings it up, I'm well aware of CakePHP... and > don't > > > care for it much.) > > > > > > There are times in D when I find myself wishing, momentarily, for the > > > loose typing of Ruby... but then there are times in Ruby when I find > > > myself wishing for stricter typing. > > > > > > There are times when I wish D had open classes... but then there are > > > times when Ruby's open classes give me headaches. > > > > > > I could go on like this... but the point was really just: use the right > > > tool for the job. Keep several tools in your toolbox. There is no > "THE > > > BEST LANGUAGE OMG!!!" There is just the best one for a given > programmer > > > in a given scenario. Some of the things I've done could probably have > > > been better written in, say, Pike! But I don't really know Pike (very > > > well), and don't feel the need to learn it just for those few things > > > that might have benefited. > > > > > > -- Chris N-S > > > > Agreed. One issue with the talk is non-acceptance of "the right tool for > > the job" (the speaker literally says he's tired of that phrase). There > > is one best tool - and that's Ruby. Ahem. > > LOL. I'd _love_ to use D at work, but so much of our code is in C++ and > must > compile with Visual Studio that the fact that C++ doesn't integrate with D > all > that well and the fact that you have to use dmc on Windows for the C or C++ > code > if you want to link it with D code make it so that it doesn't make any > sense at > all to use D at this point. > > And of course, there are plenty of cases where a particular language is > just > incredibly well suited for a particular job, and the best general purpose > language just isn't as good. > > I think that it's good to strive to a have a language that is excellent for > most > use cases, but ultimately, you always have to pick the best tool for the > job. No > language is the best for all scenarios even if it's the best for most > scenarios. > > - Jonathan M Davis >
Re: Looking for champion - std.lang.d.lex
so that was 4 months ago - how do things currently stand on that initiative? -Mike On Fri, Nov 19, 2010 at 6:37 PM, Bruno Medeiros wrote: > On 19/11/2010 22:25, Michael Stover wrote: > >> As for D lexers and tokenizers, what would be nice is to >> A) build an antlr grammar for D >> B) build D targets for antlr so that antlr can generate lexers and >> parsers in the D language. >> >> For B) I found http://www.mbutscher.de/antlrd/index.html >> >> For A) A good list of antlr grammars is at >> http://www.antlr.org/grammar/list, but there isn't a D grammar. >> >> These things wouldn't be an enormous amount of work to create and >> maintain, and, if done, anyone could parse D code in many languages, >> including Java and C which would make providing IDE features for D >> development easier in those languages (eclipse for instance), and you >> could build lexers and parsers in D using antlr grammars. >> >> -Mike >> > > Yes, that would be much better. It would be directly and immediately useful > for the DDT project: > > "But better yet would be to start coding our own custom parser (using a > parser generator like ANTLR for example), that could really be tailored for > IDE needs. In the medium/long term, that's probably what needs to be done. " > in > http://www.digitalmars.com/d/archives/digitalmars/D/ide/Future_of_Descent_and_D_Eclipse_IDE_635.html > > -- > Bruno Medeiros - Software Engineer >
Re: Looking for champion - std.lang.d.lex
As for D lexers and tokenizers, what would be nice is to A) build an antlr grammar for D B) build D targets for antlr so that antlr can generate lexers and parsers in the D language. For B) I found http://www.mbutscher.de/antlrd/index.html For A) A good list of antlr grammars is at http://www.antlr.org/grammar/list, but there isn't a D grammar. These things wouldn't be an enormous amount of work to create and maintain, and, if done, anyone could parse D code in many languages, including Java and C which would make providing IDE features for D development easier in those languages (eclipse for instance), and you could build lexers and parsers in D using antlr grammars. -Mike On Fri, Nov 19, 2010 at 5:09 PM, Bruno Medeiros wrote: > On 27/10/2010 22:43, Nick Sabalausky wrote: > >> "retard" wrote in message >> news:iaa44v$17s...@digitalmars.com... >> >>> >>> I only meant that the widespead adoption of Java shows how the public at >>> large cares very little about the performance issues you mentioned. >>> >> >> The public at large is convinced that "Java is fast now, really!". So I'm >> not certain widespread adoption of Java necessarily indicates they don't >> care so much about performance. Of course, Java is quickly becoming a >> legacy >> language anyway (the next COBOL, IMO), so that throws another wrench into >> the works. >> >> >> > Java is quickly becoming a legacy language? the next COBOL? SRSLY?... > Just two years ago, the now hugely popular Android platform choose Java as > it's language of choice, and you think Java is becoming legacy?... > > The development of the Java language itself has stagnated over the last 6 > years or so (especially due to corporate politics, which now has become even > worse and uncertain with all the shit Oracle is doing), but that's a > completely different statement from saying Java is becoming legacy. > In fact, all the uproar and concern about the future of Java under Oracle, > of the JVM, of the JCP (the body that regulates changes to Java),etc., is a > testament to the huge popularity of Java. Otherwise people (and > corporations) wouldn't care, they would just let it wither away with much > less concern. > > > -- > Bruno Medeiros - Software Engineer >
Re: The Expressiveness of D
I don't see how compiling to native prevents the source code from expressing
high-level concepts in a reasonable way. Lisp is compiled to naitve code.
Even Java can be compiled to native code. And frankly, that has little to
do with speed and memory usage. The memory usage is largely from the
garbage collector, and thus is still there even when compiling to native. I
imagine D has that issue too.
-Mike
On Tue, Nov 2, 2010 at 9:27 AM, Gary Whatmore wrote:
> %u Wrote:
>
> > %u Wrote:
> >
> > > I found a slideshow called 'The Expressiveness of Go' recently. The
> conclusions are:
> > >
> > > * Go is not a small language but it is an expressive and comprehensible
> one.
> > >
> > > * Expressiveness comes from orthogonal composition of constructs.
> > >
> > > * Comprehensibility comes from simple constructs that interact in
> easily understood ways.
> > >
> > > * Build a language from simple orthogonal constructs and you have a
> language that will be easy and productive to use.
> > >
> > > * The surprises you discover will be pleasant ones.
> > >
> > >
> > >
> > > Is D orthogonal? Could it be more orthogonal? Two things come to my
> mind: removing special cases and making widely used things first class. For
> data types this means that they have literals, can be given to functions and
> returned from functions. I made a small test and found that the discoveries
> aren't pleasant to me:
> > >
> > >
> > > class A {}
> > > class B : A {}
> > > class C : A {}
> > >
> > > template T(A...) { alias A T; }
> > >
> > > void main() {
> > > auto a = true ? new B : new C;
> > > // these don't work - why?
> > > // auto b = [new B, new C];
> > > // auto c = { return [1: new B,2: new C]; };
> > >
> > > T!(int,int) e = (1,2);
> > > e = T!(3,4);
> > >
> > > // ah - so (1,2) syntax on initialization, T!(1,2) when assigning!
> > > T!(int,int) d = T!(1,2);
> > >
> > > e = d;
> > >
> > > // tuples aren't first class, why?
> > > // auto f = { return e; };
> > > }
> >
> > I then test this in Scala REPL:
> >
> > scala> class A; class B extends A; class C extends A
> > defined class A
> > defined class B
> > defined class C
> >
> > scala> val a = List(new B,new C)
> > a: List[A] = List(b...@1f18cd5, c...@154f6ff)
> >
> > scala> val b = Map(1 -> new B, 2 -> new C)
> > b: scala.collection.immutable.Map[Int,A] = Map((1,b...@14512e),
> (2,c...@1ddbcb1))
> >
> > scala> var e = (1,2)
> > e: (Int, Int) = (1,2)
> >
> > scala> e = (3,4)
> > e: (Int, Int) = (3,4)
> >
> > scala> val d = (1,2)
> > d: (Int, Int) = (1,2)
> >
> > scala> e = d
> > e: (Int, Int) = (1,2)
> >
> > scala> val f = () => e
> > f: () => (Int, Int) =
> >
> > scala> f()
> > res0: (Int, Int) = (1,2)
>
> My eyes radiate red light of hate every time I see these comparisons
> between D and some slower virtual machine language. Of course the virtual
> machine languages are simpler to use and look nice. That's their way to lure
> you into using them. Boom! Suddenly 200% larger memory usage and 50% to 90%
> of the processing power is lost. Building a native language doesn't have all
> mumbo jumbo JIT daemons running there. Thus the code has to optimized at
> compile time and that's why those codes above are more complex in D and
> don't work.
>
> - G.W.
>
Re: What would you rewrite in D?
An operating system written in D would be really interesting. On Thu, Oct 14, 2010 at 11:05 AM, Andrej Mitrovic < andrej.mitrov...@gmail.com> wrote: > On 10/6/10, Nick Sabalausky wrote: > > "sybrandy" wrote in message > > news:i8g8oi$1hv...@digitalmars.com... > >> Just asking out of curiosity. With all the great language features, I'm > >> sure that many of you have thought about this. > >> > >> For me, I figured a good start would be your basic Unix/Linux/BSD > >> utilities, like cat and grep. I figure it may make the code easier to > >> read and maintain as well as potentially improve the quality of the > >> software. Of course, most of these are so old they're probably quite > bug > >> free, but some probably could use a rewrite. Some may even benefit for > >> threading. > >> > > > > Not that I would want to do it myself, but I'd like to see LLMV and > > Scintilla moved to D. > > > > But really, just about anything in C/C++ that I might ever want to > modify. > > If I never have to touch another line of C/C++ it'll be too soon. > > > > > > > > FYI, there's a DFL Scintilla component you can use in D2, which is > downloaded separately from DFL. I've made a small update to it in the > DFL forums although you would also need to add one more method in the > scintilla class to get messages back from Scintilla itself (I'll post > an update to the DFL forums some time later for that). > > So basically the DFL component loads the scintilla DLL, and you can > use message passing or optionally get a function pointer for direct > access. It's really easy to use the editor from D in this way. In > fact, you can port *Scite* source code to a D equivalent that uses the > Scintilla DLL with ease. It only took me a minute to port the > automatic indentation functionality from Scite to a fresh project that > uses the DFLs Scintilla class. > > I wouldn't know if there are any bottlenecks in the Scintilla > codebase, so I can't judge if it's worth porting to D. But it already > works and you can use it from D already, so why go through all the > trouble of rewriting it? :-) >
Re: What do people here use as an IDE?
Read it's home page. In bold letters, it says *This project is dead. Please use http://code.google.com/a/eclipselabs.org/p/ddt/* * * *I take them at the word since I don't know any better :-) * On Tue, Oct 12, 2010 at 10:20 PM, Eric Poggel wrote: > On 10/12/2010 10:11 PM, Michael Stover wrote: > >> Descent is a dead project, replaced by DDT which doesn't have a release. >> Also, I'm running Linux at home and Mac at work, so VisualD won't do for >> me. Poseidon is also Windows-only. >> > > Descent is dead? The change log shows recent activity ( > http://dsource.org/projects/descent/log/) >
Re: What do people here use as an IDE?
Why would I laugh? I've been using Eclipse for nearly 10 years. Descent claims to be a dead project, so I'm curious that you say you use it - what version of Eclipse are you using with it? DDT is it's replacement and it has no release. On Tue, Oct 12, 2010 at 10:18 PM, Eric Poggel wrote: > On 10/12/2010 9:57 PM, Michael Stover wrote: > >> Elephant appears dead. Poseidon's activity is extremely low and is >> still alpha after 5 years. LEDS is even less active, and DDT doesn't >> have a release yet. What do actual D programmers use? >> >> -Mike >> > As an Eclipse fan (don't laugh!) I've been using Descent for a couple of > years now with good results. I think others here may use VisualD. >
Re: What do people here use as an IDE?
Seems to me if D really wants to compete, a modern IDE is essential. On Tue, Oct 12, 2010 at 10:05 PM, Clark Gaebel wrote: > Doesn't really count as an IDE, but I use vim for all development, and > the d-syntax package from the d overlay in gentoo portage was all I > really needed to get started. > > Kudos to the maintainer of the d portage overlay by the way. Your work > is appreciated! > > On 10/12/10 22:01, Jimmy Cao wrote: > > I'm by no means an "actual D programmer" but I like to use Code::Blocks. > > I've heard VisualD and Descent are also very nice. > > There's also a guy working on D.dev ( > > http://d-dev-ide.blogspot.com/2010/07/ddev-progress-july-2010.html). > > > > On Tue, Oct 12, 2010 at 8:57 PM, Michael Stover > > wrote: > > > >> Elephant appears dead. Poseidon's activity is extremely low and is > still > >> alpha after 5 years. LEDS is even less active, and DDT doesn't have a > >> release yet. What do actual D programmers use? > >> > >> -Mike > >> > > -- > Regards, > -- Clark > >
Re: What do people here use as an IDE?
Descent is a dead project, replaced by DDT which doesn't have a release. Also, I'm running Linux at home and Mac at work, so VisualD won't do for me. Poseidon is also Windows-only. Do you use a plugin for Code::Blocks specific for D? On Tue, Oct 12, 2010 at 10:01 PM, Jimmy Cao wrote: > I'm by no means an "actual D programmer" but I like to use Code::Blocks. > I've heard VisualD and Descent are also very nice. > There's also a guy working on D.dev ( > http://d-dev-ide.blogspot.com/2010/07/ddev-progress-july-2010.html). > > > On Tue, Oct 12, 2010 at 8:57 PM, Michael Stover < > michael.r.sto...@gmail.com> wrote: > >> Elephant appears dead. Poseidon's activity is extremely low and is still >> alpha after 5 years. LEDS is even less active, and DDT doesn't have a >> release yet. What do actual D programmers use? >> >> -Mike >> > >
What do people here use as an IDE?
Elephant appears dead. Poseidon's activity is extremely low and is still alpha after 5 years. LEDS is even less active, and DDT doesn't have a release yet. What do actual D programmers use? -Mike
Re: Call C (or C++) with pointer to static function
Thank you, I have checked them out. Both SciD and dstats look useful. We would have to supplement with our own math libraries and bindings to various C/Fortran libraries I think. I am just exploring possibilities because of the endless troubles we have with compiling and linking C++ code on Mac, Linux, and Windows and thus why we've never compiled our math models (which makes them really slow). For estimation problems, it's just not workable without compiling the model at runtime to native code. It was my thought that D would make the step easier and faster than C++. But is does have to work on Mac, Windows, and Linux user desktops. -Mike On Mon, Oct 11, 2010 at 9:56 AM, Lars T. Kyllingstad wrote: > On Sun, 10 Oct 2010 20:30:52 -0400, Michael Stover wrote: > > > Can one call fortran libraries from D? Ie, say one wanted to use LAPACK > > from D? > > Since it is possible in C, it should be possible in D. A quick search > turned up this page: > > http://www.yolinux.com/TUTORIALS/LinuxTutorialMixingFortranAndC.html > > When it comes to LAPACK (and BLAS), Bill Baxter has already written D1 > bindings. I've converted them to D2 and published them (with his kind > permission) as part of SciD (see scid.bindings.*). Which brings me to > your next question... > > > > Also, know of any mathematical libraries written in D (like > > implementations of runge-kutta, linear algebra routines and data > > structures, optimization or curve-fitting algorithms)? > > Of the things you mention, SciD only contains a few linear algebra > routines (see scid.linalg and the aforementioned BLAS/LAPACK bindings). > There may be other things you'll find useful in there, though: > > http://www.dsource.org/projects/scid > > Also, check out this list (may not be up to date): > > http://www.prowiki.org/wiki4d/wiki.cgi?ScientificLibraries > > > -Lats >
Re: Call C (or C++) with pointer to static function
Thank you for helping me understand.
Mike
On Mon, Oct 11, 2010 at 8:39 AM, Simen kjaeraas wrote:
> Michael Stover wrote:
>
> I am under the impression that passing a pointer to a static function (ie,
>> passing a pointer to a memory address that contains the starting point of
>> a
>> function) is not the same as defining a method that can be called by name
>> from C code. I am not a C expert though.
>>
>
> Well, yes and no. Given
>
>
> extern( C ) returnType myFunc( /* args */ ) {}
>
> You still have no function pointer to it. That is however easy to procure:
>
> someCfunctionThatExpectsAfnPointer( &myFunc );
>
> It could be that there is some hidden detail of C static functions that I
> don't know, but i believe this works.
>
>
>
> Can one call fortran libraries from D? Ie, say one wanted to use LAPACK
>> from D?
>>
>
> http://dsource.org/projects/scid uses LAPACK, so I guess it is possible.
>
>
> Also, know of any mathematical libraries written in D (like
>> implementations
>> of runge-kutta, linear algebra routines and data structures, optimization
>> or
>> curve-fitting algorithms)?
>>
>
> At least some of this has been mentioned time and time again on the
> newsgroup, you should be able to find it by searching.
>
> From dsource.org/projects:
>
> http://dsource.org/projects/scid
> http://dsource.org/projects/dstats
>
> --
> Simen
>
Re: Call C (or C++) with pointer to static function
I am under the impression that passing a pointer to a static function (ie,
passing a pointer to a memory address that contains the starting point of a
function) is not the same as defining a method that can be called by name
from C code. I am not a C expert though.
Can one call fortran libraries from D? Ie, say one wanted to use LAPACK
from D?
Also, know of any mathematical libraries written in D (like implementations
of runge-kutta, linear algebra routines and data structures, optimization or
curve-fitting algorithms)?
-Mike
On Sun, Oct 10, 2010 at 5:10 PM, Simen kjaeraas wrote:
> On Sun, 10 Oct 2010 22:03:51 +0200, Michael Stover <
> michael.r.sto...@gmail.com> wrote:
>
> I am wondering if D would be a good choice for our differential equation
>> modeling app. What it needs to be able to do is dynamically compile D
>> code
>> into a static function that can then be used to call C-code that expects a
>> pointer to a static function.
>>
>> Longer description:
>> It is a desktop app. The user writes equations. I'd like to be translate
>> the equations into D code, compile it, and then call C code that
>> represents
>> optimizing or solver procedures. These functions expect a pointer to a
>> static function that calculates the values of the equations, which would
>> be
>> the D code just compiled.
>>
>> Is this feasible with D2?
>>
>
> Absolutely. The dynamic compilation part is not directly supported, but
> possible. There are several ways of accomplishing this, from Burton
> Radon's (outdated, proof-of-concept only) dynamic compilation[1], to
> calling the C functions in the generated D code, and pipe the output
> where you need it.
>
> Interfacing to C is detailed on this page:
> http://digitalmars.com/d/2.0/interfaceToC.html
>
> And can mostly be summarized like this:
>
> Create a D function that is callable from C:
> extern( C ) returnType myFunc( /* args */ ) {}
>
> Refer to a C function that is callable from D:
> extern( C ) returnType myFunc( /* args */ );
>
>
> [1]:
> http://members.shaw.ca/burton-radons/The%20Joy%20and%20Gibbering%20Terror%20of%20Custom-Loading%20Executables.html
>
> --
> Simen
>
Call C (or C++) with pointer to static function
I am wondering if D would be a good choice for our differential equation modeling app. What it needs to be able to do is dynamically compile D code into a static function that can then be used to call C-code that expects a pointer to a static function. Longer description: It is a desktop app. The user writes equations. I'd like to be translate the equations into D code, compile it, and then call C code that represents optimizing or solver procedures. These functions expect a pointer to a static function that calculates the values of the equations, which would be the D code just compiled. Is this feasible with D2? Thanks, Michael Stover
