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 alvaro.seg...@gmail.com 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
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 destructiona...@gmail.comwrote: 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
On Thu, Dec 16, 2010 at 2:22 PM, Nick Sabalausky a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com 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
On Thu, Dec 16, 2010 at 2:48 PM, Nick Sabalausky a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com 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
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 a...@a.a wrote: Adam D. Ruppe destructiona...@gmail.com 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
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 destructiona...@gmail.comwrote: 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 select 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 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 destructiona...@gmail.comwrote: 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
On Wed, Dec 15, 2010 at 2:26 PM, retard r...@tard.com.invalid 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
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 a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com 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
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 a...@a.a wrote: David Nadlinger s...@klickverbot.at 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
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 destructiona...@gmail.comwrote: 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
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 a...@a.a wrote: Michael Stover michael.r.sto...@gmail.com wrote in message news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com... On Wed, Dec 15, 2010 at 2:26 PM, retard r...@tard.com.invalid 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
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 destructiona...@gmail.comwrote: 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
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 destructiona...@gmail.comwrote: 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
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: emscripten
On Tue, Dec 14, 2010 at 2:03 PM, Adam Ruppe destructiona...@gmail.comwrote: 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 destructiona...@gmail.com 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
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 destructiona...@gmail.comwrote: 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
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 destructiona...@gmail.comwrote: 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: 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 jmdavisp...@gmx.comwrote: 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
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 brunodomedeiros+s...@com.gmail wrote: On 27/10/2010 22:43, Nick Sabalausky wrote: retardr...@tard.com.invalid 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: 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 brunodomedeiros+s...@com.gmail 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: 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 a...@a.a wrote: sybrandy sybra...@gmail.com 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? :-)
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: 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 jcao...@gmail.com 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
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 cg.wowus...@gmail.comwrote: 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 michael.r.sto...@gmail.comwrote: 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?
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 dnewsgro...@yage3d.netwrote: 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?
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 dnewsgro...@yage3d.netwrote: 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: 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 simen.kja...@gmail.comwrote:
Michael Stover michael.r.sto...@gmail.com 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
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 pub...@kyllingen.nospamnet 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
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
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 simen.kja...@gmail.comwrote:
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
