Language:
switch to room list switch to menu My folders
Go to page: First ... 104 105 106 107 [108] 109 110 111 112 ... Last
[#] Fri Dec 19 2014 08:39:29 EST from fleeb @ Uncensored

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


I think my problems involve TortoiseHg's default settings. They automatically push my commits to the remote repository, when I'd rather resolve things locally first.

I may need to investigate this a little further. In the meantime, following some advice I should have ignored, I managed to really fubar the repository after a particularly errant merge.

Maybe, possibly, permissions should be established to prevent me from doing something so dangerous.

[#] Tue Dec 23 2014 00:16:53 EST from ax25 @ Uncensored

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

I hear you IG.  I have found myself re-explaining the ways of the Cederqvist cvs manual to those that could not be bothered with reading that ancient history.

As to the Tortoise gui overlay on Windows Explorer.  I guess I would have to say that I gave up on that back in the days of Win95 as it did unexpected things to me as well.  I did give the Bzr tools and gateway tools to other repositories a try back a few years ago and had some success, but became mostly just a sysadmin after some point.

I found the Bzr add on tools that converted what I knew in Bzr to (whatever repo) to work with my mindset the best.  But from what little I looked, Bzr is probably on the way out compared to the new hotness Git.  Good luck, and post back your findings so others can avoid breaking toes on the rocky bottom bits of the river. 



[#] Tue Dec 23 2014 08:09:28 EST from IGnatius T Foobar @ Uncensored

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

Everything is on its way out except Git and for some reason, Hg.

[#] Fri Dec 26 2014 08:34:45 EST from fleeb @ Uncensored

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


This TortoiseHg that I'm using is on a Linux system, but still acts oddly.

I'm lead to believe that there are default settings that need to be fixed to make the tool act the way I should expect.

Which is kind of dumb, honestly.

[#] Sat Dec 27 2014 13:22:18 EST from dothebart @ Uncensored

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

well, the linux experience is not as nice as the windows one (to be honest)

the hg manager which you can open from thg is way to complex at first sight; disabling the mq with it is a good thing to get users used to it, and then once they know enable it.

the hg manager also has a pretty descent visualisation of the patch queues, once you have it.

I like it a lot. git stash is nice, but, the visualisations aren't that nice.



[#] Sat Jan 03 2015 15:27:09 EST from IGnatius T Foobar @ Uncensored

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


Has anyone ever tried/used the "Duktape" javascript engine? [ http://duktape.org/ ]

It seems to be aimed at being small, portable, and easy to embed, rather than focusing on speed.

As many of you know, I have been looking for such a thing. This appears to be "it" but I'm concerned that it has to be a project that is likely to be around and maintained for the foreseeable future.

[#] Sat Jan 03 2015 23:34:03 EST from ax25 @ Uncensored

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

https://github.com/abe-winter/duktape-py

Thanks for the heads up IG.  Early days indeed, but looks like a fun alternative to firing up a browser or using V8 for Python.



[#] Sun Jan 04 2015 13:36:58 EST from dothebart @ Uncensored

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

I think a collegue of mine has been taking a look at it, and was pretty fond of its interface.

maybe he will tell me more tomorow.

Fiddling about the V8 api for 2 months now, I think the choice can't be that bad.



[#] Wed Jan 07 2015 17:55:56 EST from IGnatius T Foobar @ Uncensored

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

ax25: that's fascinating, but what kind of application calls for a scripting language to be embedded into another scripting language? Or are you trying to make use of a library in the other language?

[#] Wed Jan 07 2015 19:09:27 EST from dothebart @ Uncensored

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

I guess if you've got a build system in python (scons) it makes sense to be able to call jsmins implemented in javascript (which seems to be quiet common nowadays...) without spawning a new process...

 



[#] Thu Jan 08 2015 23:56:21 EST from ax25 @ Uncensored

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

IG, much evaluation...  If you want to do much automated stuff on the web (in Python), you need to either run a JS engine (like V8), to get the code working, or something like this lib.  I have not tried it yet, but it looks like it will scratch an itch for me in quite a few ways on some stalled projects that I have shelved due to how messy a process it is to deal with web pages with javascript in them in Python.  If I am wrong, and there is something I am overlooking, I would love to be enlightened!



[#] Fri Jan 09 2015 03:47:51 EST from dothebart @ Uncensored

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

finaly you have to know that many QA web stuff is done in python (i.e. selenium)

another means for that is phantom js:

http://phantomjs.org/



[#] Fri Jan 09 2015 08:03:15 EST from ax25 @ Uncensored

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

I have used selenium, but had not tried PhantomJS.  That sounds like a keeper as well.



[#] Sat Jan 10 2015 14:02:16 EST from IGnatius T Foobar @ Uncensored

[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 16:37:07 EST from dothebart @ Uncensored

[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 16:41:34 EST from dothebart @ Uncensored

[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 11:04:34 EST from fleeb @ Uncensored

[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 11:51:17 EST from dothebart @ Uncensored

[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 14:39:33 EST from IGnatius T Foobar @ Uncensored

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

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

[#] Mon Jan 12 2015 15:20:19 EST from fleeb @ Uncensored

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


Heh, I figured as much. Hm...

Go to page: First ... 104 105 106 107 [108] 109 110 111 112 ... Last