Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 8 9 10 11 [12] 13 14 15 16 ... Last
[#] Sat Jan 10 2015 19:02:16 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Obviously for a web browser you want the fastest possible JavaScript interpreter at all costs. V8 kicks butt there, but it's saddled with portability and build complexity problems that make it impractical to simply bolt on to an application that just needs some simple scripting added to it. Duktape looks attractive because it's just a .c and a .h file you link in to your application, bang zoom done.

By the way, it's a good thing that Visual Basic never caught on as a browser scripting language during aIEeee's market share peak years. That would have been miserable.

Anyway, if Duktape ends up being any good, I may consider it as a scripting engine for Citadel. I like Python as much as the next guy, but we've already got so much of the web-side platform written in JavaScript, there are a lot of possible synergies there, and the benefit of not having to get our build system to deal with the host's Python universe is a big win.

[#] Sun Jan 11 2015 21:37:07 UTC from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

yea, V8 is only portable to ARM, i386 and x64, which in our situation is not acceptable.

However, the biggest server side ecosystem was developed for the V8 ecosystem: nodejs.

so, pure library portability will only be there for V8 - which is why triangens hat chosen it for arangodb.

when google forked webkit, they did this for a reason. it clung them to an API which they didn't want to follow anymore, since it had performance implications.

the result is, that V8 did a fundamental api change, which in the case of arango took a lot of hard work to follow. For node this also was a major undertaking, the results aren't released yet.

put short, V8 users != chrome are second class citizens.

there are two more js engines which one shouldn't forget about:

spidermonkey: highly portable, and they claim to be fast... sort of http://www.webmonkey.com/2010/09/mozilla-asks-are-we-fast-yet/

The apple engine - as one may expect, apple wants to leverage its existing eco system to get the best for the buck. As you all know, apple invested heavily in LLVM & CLang - so - yes, this became their solution.

Last summer they published their new kid: https://trac.webkit.org/wiki/FTLJIT

 

While this binds one to the LLVM compiler infrastructure, it sounds most interesting to me...



[#] Sun Jan 11 2015 21:41:34 UTC from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

oh, yes, and while python aims to be easily integrateable, its not a lightweight thing to compile, neither are its dependencies.

So, no chance to do this and the third language in the game is also not acceptable.



[#] Mon Jan 12 2015 16:04:34 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Off the current topic, but does anyone here familiar with engines like PHP know if you take a performance hit for building libraries with functions that may not be used by those including the file in their page?

That is, if I created an object with functions that puts data in a database, or retrieves data from the database, those pages that only need to put data in the database might get impacted by the fact that there's code for putting data in the database (which won't get called, but gets pulled in by an include statement anyway)... is that true or false? Or sorta?

(sorry if I'm using particularly terrible English to ask this, my head is in a weird place right now)

[#] Mon Jan 12 2015 16:51:17 UTC from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

requiring additional php files requires additional processing power consumption

if its that what you were asking.

php has to stat the files, load it, parse it, etc.



[#] Mon Jan 12 2015 19:39:33 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

...unless you're Facebook and compile all of your PHP, but ... it's complicated.

[#] Mon Jan 12 2015 20:20:19 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Heh, I figured as much. Hm...

[#] Mon Jan 12 2015 20:33:41 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I think that answers my question.

I figured that the PHP engine has to include the file, interpret what it included (which involves the stuff that you don't intend for the consumer of a library to use as well as the stuff the consumer will use), and make any functions within the included file available to the consumer.

So, hmmm... the next bit is knowing if it takes more processing power to read a new file in than to have a bunch of extra stuff in the included file.
Or, rather, more time ... processing power might be even less, but the file itself might take more time because of having to stat it, read the file in, etc.

It's just a whole side of things I haven't had to think about until now.
With a compiled language, you know that the compiler has done some up-front work in dealing with all this stuff, and the output is something that's kind of streamlined to do what you need. Not exactly the same with a scripting language, where an interpreter has to parse everything in advance.

[#] Tue Jan 20 2015 18:06:39 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


ProTip:

Recursive functions tend not to come all the way back down the stack if they have a statement like "sys.exit(0)" in them.

<< SMH >>

I spent half a day rewriting code and ultimately wondering whether Python actually has recursion before finding that I had put that trace point in my function. /me needs either more coffee or less, dunno which...

[#] Tue Jan 20 2015 19:17:42 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


As a general rule, I avoid exit() statements, preferring to use block structures and whatnot, for reasons like this.

Unfortunately, apparently, in PHP, using nested blocks is discouraged according to a popular standard of style used by that community, as they regard nested blocks as 'difficult to read'.

I disagree, but conform to their standards when working with others.

[#] Tue Jan 20 2015 20:43:09 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

All true, but in this case I had put the exit() statement in there two days ago because I had wanted the program to stop cold dead after printing out some traces. It was a dummy mistake.

[#] Tue Jan 20 2015 21:14:59 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Heh... I expect it stopped cold dead rather nicely.

[#] Tue Jan 20 2015 22:26:28 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Yes. In Python the official syntax is "import maxwell_silver_hammer"

[#] Fri Jan 23 2015 00:23:45 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Recursive functions tend not to come all the way back down the stack

if they have a statement like "sys.exit(0)" in them.

<< SMH >>

I spent half a day rewriting code and ultimately wondering whether
Python actually has recursion before finding that I had put that trace

point in my function. /me needs either more coffee or less, dunno
which...

You'reDoingItWrong(tm). Sys.exit(1) in Python is implemented as an exception throw. So it's actually the perfect with to terminate a recursion. Catch SysExit or whatever they call it, and you're golden. <snirk>

[#] Fri Jan 23 2015 12:20:04 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

That's brilliant. Of course, if I had written the program in JavaScript I could have replaced sys.exit() with

throw "yo dawg, I heard u liek trace messages FIXME YOU IDIOT";

[#] Thu Jan 29 2015 21:27:13 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

You'reDoingItWrong(tm). Sys.exit(1) in Python is implemented as an
exception throw. So it's actually the perfect with to terminate a
recursion. Catch SysExit or whatever they call it, and you're golden.


I've since switched to throwing exceptions when I want the program to come to a screeching halt.

The only problem is, Python doesn't allow you to throw an exception.

throw Exception("foo")

doesn't work. You can't throw an exception; you have to RAISE an exception.

F--k that ... ! If I want to throw an exception, I'm going to throw an exception!
Even if it's just an exception thrown from the fact that there's no "throw" command!

Having lived mostly in the C world for decades, though, I can see already that exception handling justifies all sorts of sloppy programming practices.
Why write good code when you can just wrap the whole damn thing in an exception handler?

[#] Fri Jan 30 2015 07:11:49 UTC from ax25

[Reply] [ReplyQuoted] [Headers] [Print]

[#] Fri Jan 30 2015 13:29:39 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I used to think exceptions were the bomb.

Now I just think they're a bomb. I prefer more explicit error handling with return codes or the like. I hate having the flow interrupted randomly by who-knows-what deep in the layers of hell.

I guess it has its place, though... I just haven't quite decided for myself where that place should be.

[#] Fri Jan 30 2015 14:15:16 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I just read a question that kind of blows my mind.

"I don't understand why cURL come into play? I thought this was using rest?
is cURL a type of rest client?"

(I copied the question literally, punctuation and capitalization errors and all).

That last question blows my mind. Is cURL a type of REST client?

It's one of those questions that exposes what feels like a fundamental misunderstanding of several subtle but important concepts. I'm thankful someone else answered it for him, because I'm not sure how I would have started without coming across as a jerk.

How does that question feel to you guys?

[#] Fri Jan 30 2015 15:12:49 UTC from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

Well, I used exception for that, and re-threw it enriching the error message all the way up the stack; Else you would have to keep some string some where... so exceptions make it more nice.



Go to page: First ... 8 9 10 11 [12] 13 14 15 16 ... Last