(October 25, 2018 at 4:46 am)FlatAssembler Wrote:

(October 23, 2018 at 2:38 am)Pandæmonium Wrote: Needs more JavaScript rain. And text that follows the mouse cursor.

I don't understand what you are saying. The web-app has around 900 lines of JavaScript. Most of that is needed for the web-app to function properly, and doesn't have much to do with what the web-app looks like.
I have recently added a feature that enables the AST-es generated by the parser to be represented graphically in modern browsers. However, the algorithm I've used doesn't appear to be quite optimal and the results are unlegible if the AST gets deeper.
So, I am asking, does anyone here have some experience with drawing tree diagrams in JavaScript? I am not so interested in it making it look nice, I am interested in making it useful.
Though I need to hold a presentation about that web-app tomorrow at the university, so it's probably too late to fix it right now.

If you are that heavily client-side, consider possibly just writing a computer app with a web interface? Visual Studio is free, and you can put together a Windows program in a day or two.

Sorry for not responding for that long, I was busy with the university. I barely got a passing score in mathematics, I am not sure if I should continue studying computer science.

Quote:If you are that heavily client-side, consider possibly just writing a computer app with a web interface? Visual Studio is free, and you can put together a Windows program in a day or two.

Well, the main reason is that JavaScript is the only language I know well enough to make that program in it. Also, it's not that heavy. The time complexity of my algorithm is cubic in the worst case (I think) and the space complexity is quadratic. It would be relatively easy to make it run in square time and possible to make it run in linear time (implementing Shunting-yard), but there appears to be no need to. No matter how long arithmetic expression I input it, it runs in an imperceptible amount of time.

The presentation went relatively well. Some students complained that they have never heard of most of the things I was talking about before, but it's very hard to explain the basic compiler-theory to somebody who is new to programming, isn't it?

I've decided to continue developing that web-app. I've designed a new layout and made it possible to download a complete command line assembly language program to test the compiler output.
I've decided to make this layout using the IE6-compatible CSS and JavaScript, and I hoped it would then work in all today's browsers. However, that notion proved false. Although IE6 renders it correctly, IE7 and IE8 refuse to even run the layout-related parts of the script and show some undecipherable error message. IE9 renders it correctly again, but the layout breaks in IE10. Fortunately, IE11 renders it correctly, and so does Safari 12 (but not Safari 5), Opera 12 and Firefox (whichever version I have installed on my other computer, I don't know that right now). That was quite a surprise for me, I've always thought Internet Explorer maintained backwards compatibility almost perfectly. Let's hope it will work correctly in Chrome, I haven't bothered to install it (I know it takes very long).

For the record, Pandaemonium was making a joke about how dated your site still looks.

(November 10, 2018 at 2:15 pm)FlatAssembler Wrote: Sorry for not responding for that long, I was busy with the university. I barely got a passing score in mathematics, I am not sure if I should continue studying computer science.

Quote:If you are that heavily client-side, consider possibly just writing a computer app with a web interface? Visual Studio is free, and you can put together a Windows program in a day or two.

Well, the main reason is that JavaScript is the only language I know well enough to make that program in it. Also, it's not that heavy. The time complexity of my algorithm is cubic in the worst case (I think) and the space complexity is quadratic. It would be relatively easy to make it run in square time and possible to make it run in linear time (implementing Shunting-yard), but there appears to be no need to. No matter how long arithmetic expression I input it, it runs in an imperceptible amount of time.

The presentation went relatively well. Some students complained that they have never heard of most of the things I was talking about before, but it's very hard to explain the basic compiler-theory to somebody who is new to programming, isn't it?

I've decided to continue developing that web-app. I've designed a new layout and made it possible to download a complete command line assembly language program to test the compiler output.
I've decided to make this layout using the IE6-compatible CSS and JavaScript, and I hoped it would then work in all today's browsers. However, that notion proved false. Although IE6 renders it correctly, IE7 and IE8 refuse to even run the layout-related parts of the script and show some undecipherable error message. IE9 renders it correctly again, but the layout breaks in IE10. Fortunately, IE11 renders it correctly, and so does Safari 12 (but not Safari 5), Opera 12 and Firefox (whichever version I have installed on my other computer, I don't know that right now). That was quite a surprise for me, I've always thought Internet Explorer maintained backwards compatibility almost perfectly. Let's hope it will work correctly in Chrome, I haven't bothered to install it (I know it takes very long).

I have to say, it's a pretty cool idea, and not something I could do.  i really (really!) feel you should be doing this kind of work server side for a few reasons.

First of all, using javascript, your entire code is completely revealed to the browser, meaning you are open to theft, and possibly even to injection attack if you haven't sanitized your input well enough.

Quote: For the record, Pandaemonium was making a joke about how dated your site still looks.

Well, the most noticeable difference between my website and a website from 1995 is that my website looks good in Mobile Chrome (as a mobile browser that allows you to do fancy stuff in JavaScript if you detect your website is being run on a mobile device, but Safari isn't one of those, and it's very hard to tell apart the browsers which would allow you to do that and ones that wouldn't by browser-sniffing) while a website from 1995 is useless in it.

Quote: i really (really!) feel you should be doing this kind of work server side

And in which programming language can it be done easily except in JavaScript? I have read that PERL is good for string and array manipulation, is it true?

Quote: meaning you are open to theft

What do you think is the point of open-source software then?

Quote: possibly even to injection attack if you haven't sanitized your input well enough.

I don't think that's possible. See, what the back-end does is to delete the old ASM file and create a new one each time it receives an AJAX. If somebody makes an Assembly-language malware and sends it to the back-end, it would be downloadable only until the next AJAX, that is, only by the person who has done that (since the download is programmed in JavaScript to start only after the AJAX has been completed).

BTW, if you tried to make some relatively-complicated layout, how would you ensure it doesn't break in various browsers? Coding it in IE6-compatible CSS and JavaScript doesn't do the trick, since what works in IE6 doesn't even necessarily work in some later versions of Internet Explorer properly (the layout I made for that web-app works in IE6, IE9 and IE11, but it breaks in IE7, IE8 and IE10).

I like C# a lot. It's java-ish but gives access to full Windows .NET libraries-- string manipulation, etc. And you can make Android ports very easily now.

---

(November 11, 2018 at 9:03 am)FlatAssembler Wrote: [BTW, if you tried to make some relatively-complicated layout, how would you ensure it doesn't break in various browsers? Coding it in IE6-compatible CSS and JavaScript doesn't do the trick, since what works in IE6 doesn't even necessarily work in some later versions of Internet Explorer properly (the layout I made for that web-app works in IE6, IE9 and IE11, but it breaks in IE7, IE8 and IE10).

I think you're safe with HTML5 + current Javascript. Anyone who can't support that doesn't deserve to be accessing a website.

It seems to me that you can do a LOT with just .css, so I can't imagine why it's not working in any of the browsers you mentioned, except IE6 and IE9, which are too old. I hope you're not still using that code that inserts inline style code! If so, then you now know exactly why not to, I guess.

I don't know anything about PERL, though PERL programmers seem to like it a whole lot. Btw you can always custom code your own string-manipulation routines. It's not really that hard, as you very well know if you're working with assembly.

If you're so set on using JavaScript, why not simply learn node.js? Full stack JavaScript apps are a thing now. Netflix, for example, uses a ton of node to spin up/destroy instances.

---

(November 11, 2018 at 9:03 am)FlatAssembler Wrote:

Quote: For the record, Pandaemonium was making a joke about how dated your site still looks.

Well, the most noticeable difference between my website and a website from 1995 is that my website looks good in Mobile Chrome (as a mobile browser that allows you to do fancy stuff in JavaScript if you detect your website is being run on a mobile device, but Safari isn't one of those, and it's very hard to tell apart the browsers which would allow

'Good' isn't a word I'd use for describing the aesthetics of your site, which, again, is what Pandaemonium was referring to. Using modern technology doesn't mean much if your design sensibilities are stuck 15-20 years in the past.

Quote: I like C# a lot. It's java-ish but gives access to full Windows .NET libraries-- string manipulation, etc.

So, does C# support regular expressions? Does it have an equivalent of the Array.prototype.splice method? My web-app relies on those things heavily.

Quote: Anyone who can't support that doesn't deserve to be accessing a website.

Well, there are times when you are forced to use an inferior browser. Obviously, when you install a new operating system, you need to use some browser to download a proper browser. Also, if you are forced to use a computer with 512MB of RAM and 1GHz Celeron processor running Windows 7 to do something on-line, Internet Explorer is the only browser that works reasonably well. Also, on my 6-years-old mobile phone, I usually use the Android Stock Browser 4.1. If some webpage can't be used in it, I copy the URL to Chrome. But Chrome freezes so often that it's usually more painful to use than Android Stock Browser. Firefox doesn't freeze that often, but it drains the battery from full to zero in less than an hour of surfing. Android Stock Browser, with all its flaws, appears to be the best mobile browser around. That's why it's important for websites and web-apps to fail gracefully, right?

Quote: except IE6 and IE9, which are too old

IE9 is too old? Almost all JavaScript frameworks still support it.
Anyway, I've tried it, the layout doesn't actually break in IE8, it just breaks in IE11 running in the compatibility mode with IE8.

Quote: I hope you're not still using that code that inserts inline style code!

Is there any other way for a layout not to break when you resize the window in IE6?

Quote: Btw you can always custom code your own string-manipulation routines.

It's a little harder to do in a language that doesn't support prototype inheritance (like JavaScript does), isn't it?

Quote: If you're so set on using JavaScript, why not simply learn node.js?

Well, because everyone says Node.JS sucks.
Does Node.JS have an equivalent of the "innerText" directive (that converts HTML to plain text)? My syntax-highlighting algorithm relies on it.

Quote: Using modern technology doesn't mean much if your design sensibilities are stuck 15-20 years in the past.

Beauty is, beyond a certain degree, in the eye of the beholder.

Wait, who says node.js sucks?  I mean, JavaScript has its warts... they've been a part of the language since its inception, and well documented, but node has been the direction the web has been going in for the last, oh, 4-5 years, for a variety of reasons, the biggest being that web apps can now be written with a single language code base, as the MEAN (MongoDB, Express.js, Angular, Node.js) stack, among others, demonstrates.  Outside of enterprise-level concerns, like it being single-threaded, and it being JavaScript, which certain developers have an irrational hatred for, how does it suck?

Regarding innerText, assuming you're talking about this: https://developer.mozilla.org/en-US/docs.../innerText (which is a property, not a directive), then, yes, it's in node.  Node is JavaScript.

Finally, with absolutely 0 malice intended, yeah, IE6 and IE9 are old. Tech moves fast, and is driven by the big world economies - US, China, certain EU countries (Germany), Japan, etc. A 6 year old mobile phone is ancient by today's standards. Ditto any PC with less than 4GB RAM. Now, obviously, you need to build your website(s) according to who your audience is, but if you're looking to grab any kind of international audience, you need to realize that most of them/us have been conditioned to a certain level of speed, functionality, and aesthetic quality. Test in Chrome. Test in Firefox. Test in Safari (if possible). Test in Edge (if possible). Anything else really isn't worth the time unless you know for a fact that your audience is using legacy tech.

Quote: Node is JavaScript.

Well, that's great. I can't read about it on Mozilla Developer Network right now. The layout of their website gets broken completely (being illegible) in the Android Stock Browser, it loads terribly slow in Mobile Chrome (perhaps partly because I can't even get 1mbps mobile Internet speed here), and my laptop (which I can connect with a cable to a router which allows me some 10mbps Internet speed) isn't working right now.
I've always assumed NodeJS was basically Nashorn with some web-server framework added to it. Nashorn is a JavaScript engine, but it doesn't support HTML DOM at all (and innerText is a part of HTML DOM, and not JavaScript itself). Hell, you can't even use setTimeout without some weird hacks in Nashorn. It's a lot easier to tweak a JavaScript program to work in Internet Explorer 6 than to work in Nashorn.
I've tried to use some Nashorn back when I tried to learn Java, because it's a part of the Java Developer Kit.

Quote:A 6 year old mobile phone is ancient by today's standards.

I don't quite understand why some people buy new mobile phones every now and then. A decent mobile phone costs more than an average monthly wage. It's true in Croatia, and it's even more true in Serbia and Bosnia and Herzegovina, where the prices are generally the same, but the wages are lower. And that's assuming you are lucky and the phone doesn't need to be repaired soon. My experience has taught me that mobile phones usually cost around a half more than their price because they stop working quite a few times in the first few months.
And, frankly, I don't see that mobile phones are getting better. They are usually larger than they used to be, and therefore harder to handle and easier to break (especially with those infinite displays). And mobile browsers are still a pain to develop for, and therefore to use. They are full of quirks (I still haven't managed to make some features of my website work in Safari on iPhone) and you need to use alerts and search-bar-JavaScript to debug, much like in Internet Explorer 6 (even worse because you don't have a keyboard and a mouse to edit the search-bar-JavaScript with).
Those are just my thoughts, maybe I am missing something.