IRC Log Viewer » #firebreath » 2012-10-05

IRC Nick Time (GMT-7) Message
JuanDaugherty 06:10 so do I understand correctly that you do do 64 builds, unclear if you were just relaying reports of others?
in particular interested if you do anything with standard defines such as _WIN64
taxilian 10:10 JuanDaugherty: I've done it before, but not recently. Others have, though, and haven't reported any need to add defines; sounds like that might be a good thing to add by default, though
reichi 10:10 maybe some has a totally genius tip for me today regarding a javascript issue i am currently encoutring...
i have a page using prototypejs
i can produce a case where the "onSuccess" callbacks of Ajax.Request get once
and never again after that
EXCEPT i press "refresh" oder leave the page otherwise
then all of them are being called at once
and the worst thing
this happens on chrome and firefox
this is one of the most "scary" problem i ever came across
it makes things looks so incredibly broken... i don't even have a clue where i should start looking...
JuanDaugherty 10:10 you might try jquery or another js pkg
reichi 10:10 mmh no
JuanDaugherty 10:10 i would encourage one as the only
reichi 10:10 i won't rewrite 20k lines of js
JuanDaugherty 10:10 *wouldn't
reichi 10:10 jsut to "give it a try" ;9
or well no
it's not that much
but i can't rewrite it
not option
3 weeks of work
JuanDaugherty 10:10 if you've written 20 KSLOC of js completely enmeshed in prototype, which actually is rather small
then you should be an expert on it now
reichi 10:10 well no
it's not that much ;)
that was way to much
i guess it's more like 4k
JuanDaugherty 10:10 well at least js as a lang is pretty simple
reichi 10:10 well
JuanDaugherty 10:10 but I don't actually think of c++ as that complex
reichi 11:10 for some reason it seems that the execution of the code in that very special case breaks
something put's it on hold
JuanDaugherty 11:10 except for the social flack aroung it, latest stuffs whatever
reichi 11:10 which solves on closing the page
maybe prototypejs is broken
i guess i'll have to take the full-source prototypejs
to even have a chance of understanding...
JuanDaugherty 11:10 stable prototype is probably not broken
reichi 11:10 well probably
JuanDaugherty 11:10 wasn't it frozen/dead for a long time?
reichi 11:10 it just slowed down a lot
there's still development
JuanDaugherty 11:10 yeah I know it started back up
it has a very clean conservative approach
reichi 11:10 i don't like jquery
since i had a look at it's code :/
JuanDaugherty 11:10 that seems the opposite of jqueary
which is actually kinda horrific in some ways
but there's no dearth of these pkgs
it's not like the fb situation
reichi 11:10 :)
JuanDaugherty 11:10 there's a bunch of good ones
reichi 11:10 fb rocks
so there's no need to have an alternative ;)
JuanDaugherty 11:10 well it's the only thing worth considering in its niche
i guess that's a kind of rocking
but it's not comparable to the deal with js pkgs
reichi 11:10 oh man
i'm getting lcoser and closer
and i do like it less and lesser ;)
JuanDaugherty 11:10 i used to think c++ was overly complex, but my perspective changed
reichi 11:10 oh
I still think c++ is the most complex language
javascript is messy
but that has nothing to do with complexity
JuanDaugherty 11:10 the c++ and lisp cultures have the touchiest meanest people in them though, which can make it harder
reichi 11:10 only with bad style and behaviour of the coder
JuanDaugherty 11:10 most computing cultures are welcoming as they must be and those are too to a certain extent
but you only have to look at logs of the respective langs freenode channels to see what I refer to
it would be great if standard c++ could displace objective c
reichi 11:10 it would've been great if apple never introduced obj c (imo)
JuanDaugherty 11:10 it was part of jobs baggage, they'll probably drop it and the other Next trappings at some point
reichi 11:10 oh god...
i found it...
it's the backend system (which is also "my" coe)
code even
taxilian 12:10 glad you found it =]
reichi 13:10 taxilian: found is the wrong word ;)
it took me until now to actually find the cause...
taxilian 13:10 heh
reichi 13:10 the fix was as simple as "request.finish()"
on the server-side
taxilian 13:10 heh
you had a pending http request that never closed the connection?
reichi 13:10 correct
ant he server has queues
taxilian 13:10 that would do it
reichi 13:10 for each thread i think
so some requestes queued up there
while the rest continued working properly
taxilian 13:10 in the future, if you were watching in the network tab in the chrome inspector you would have seen that the connections were still open
reichi 13:10 that's where i look
after 5 hours...
in the future i'll do that right away ;)
taxilian 13:10 good plan. in the future, that's almost always the place to start looking for an ajax problem; make sure it's completing and that it's the correct format =]
I was going to suggest that, but I thought you'd already found it
reichi 13:10 well yes
taxilian 13:10 anyway, going to go get lunch (if you can call my first meal for the day lunch)
reichi 13:10 at that point I've found that
taxilian 13:10 =]
be back soon
reichi 13:10 enjoy it :)
i'll go for my late-night-meal ;)
(it's 21:46 here and i am hungry, too)
jmort253 14:10 Hey @taxilian, was wondering if you had a moment to talk shop about the future of NPAPI vs Google's new PPAPI Pepper API.
FireBreathBot 14:10 jmort253: 22 Sep 03:28Z <taxilian> tell jmort253 xcode has weird issues sometimes with multiple processes; there is a way to set it to only use one or two processes and that usually speeds things up
taxilian 14:10 jmort253: sure
let me give you a summary:
currently I have no plans to support PPAPI because it is only supported by chrome which makes it useless for anything I am doing
assuming that FireBreath can be built using google's nacl compiler, it is probably possible to add support for nacl/ppapi
but I have no idea, because as mentioned before, I don't see any particular advantage to doing so
particularly because nacl isnt' useable for anything that I need; I need hardware access that it doesn't allow, as far as I know
jmort253 14:10 That's kind of what I was thinking. Packaged apps don't have NPAPI capability, but NaCL has support for PPAPI.
Only limit I see is with them withdrawing support for NPAPI that could make it tougher on packaged apps developers.
taxilian 14:10 if they do then everything I work on will have to withdraw support for Chrome
because my stuff won't work in nacl and can't
jmort253 14:10 That's what I was worried about.
taxilian 14:10 so there is nothing I can do about it
it would be a really stupid idea for them to pull the plug on NPAPI, IMO; you don't take away functionality before providing an alternative
jmort253 14:10 What's interesting though is what you just said earlier, about using NaCL to possibly integrate with Firebreath. FB is, after all, native code.
taxilian 14:10 and nacl is not a viable alternative for most things that FireBreath usually is used for
jmort253 14:10 and Google advertises NaCL as being able to seamlessly integrate native code....
This may be something I look into more....
taxilian 14:10 right; they use (if I understand correctly) a modified GCC compiler
jmort253 14:10 and I'll be sure to let you know how it goes....
taxilian 14:10 so chances are pretty good that you could make cmake use their compiler
jmort253 14:10 sounds scary, with CMake and all the dependencies :)
taxilian 14:10 and then using conditional compilation you could create an abstraction for PPAPI just like FireBreath has for NPAPI and ActiveX currently
nah; cmake is the only trick, and I'm sure there is a way to tell it to use a specific compiler
jmort253 14:10 right on
taxilian 14:10
jmort253 14:10 Alright then, I'll roll up my sleeves and start digging in. Will let you know if I hit any snags.
BTW, thanks again for the help on Stack Overflow last month! :)
taxilian 14:10 yw
harry1978 17:10 hi! do you know of any limits concerning the JSON encoder via jsoncpp used in firebreath?
it seems it doesn't like my string object bigger than about 16kb
taxilian 17:10 it's possible; no idea
harry1978 17:10 what was the biggest json encoded object / string / encoded length you've been working with? kb? mb?
taxilian 17:10 kb
I don't use it much
harry1978 17:10 do you use another library for json encoding?
taxilian 17:10 no
I just don't need json encoding in my plugin much
harry1978 17:10 do you pass javascript parameters "as is"?
taxilian 17:10 generally
harry1978 18:10 i'll take this as a consideration about passing my parameters back...
taxilian 18:10 if you have a huge data structure to return it may be better to leave it in C++ and return a JSAPI object to contain it
harry1978 18:10 i'm handling with a directory listing at the moment, which contains the absolute and relative path information (which gets in sum quite big, in productive installations even bigger). I'm checking another JSON writer mechanism at the moment, but I generally need to call a JS function in order to build up the GUI correctly
taxilian 18:10 be very very careful with that; that sounds like a potentially huge security risk
harry1978 18:10 your ears are very good on that, but the security risk is being accepted in a pre-installed environment (i.e. a portable firefox only for that application)
harry1978 20:10 when calling FB::variant_list_of for a >16kb JSON string for a later call to Invoke of a callback JS function, the JS function get (in FF) nothing, IE crashes. any way to debug this situation? .size() shows "1" (since it's really one parameter)
FB::VariantList param;
param = FB::variant_list_of(json_string);
callback->Invoke("", param);
callback is of type const FB::JSObjectPtr& callback