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

IRC Nick Time (GMT-7) Message
JuanDaugherty 05:09 wonder what he meant by "mac os extensions"?
JuanDaugherty 06:09 I had a weird thing happen in DOS. I was switching the solution back and forth from debug to release and it was taking a long time.
it changed the solution title to "yy" and now switches are quick
based on preliminary examination, I'm assuming that prep2010x64 doesn't make significant changes to FB generation so that generating a regular project and adjusting for 64 will address my earlier issue
AlexeyKhoroshilo 07:09 Hi all! Can someone give an advice? I want to make a cross-browser storage plugin and I want to serialize and deserialize FB::variant. Something like: ofstream << fb_variant. Is there any way to do this quick and simple or I have to write converters for all possible types and wrap them somehow? And can I serialize FB::JSObject? Thanks! :)
JuanDaugherty 07:09 did you look at the IndexedDB case?
http://www.firebreath.org/display/documentation/FireBreath+Examples
there's a bit of a computer tooth fairy longing in your request but taxilian or others may respond more helpfully
taxilian 09:09 AlexeyKhoroshilo: there is a function that will convert a FB::variant to json
but it won't convert a FB::JSObject
if you want to do that you'll probably need to use the browser's json.stringify
JuanDaugherty 13:09 taxilian, ping
taxilian 13:09 JuanDaugherty: pong, your latency is ~ 1 minute
JuanDaugherty 13:09 :)
question is about VS vs FB
taxilian 13:09 the epic battle?
JuanDaugherty 13:09 just wondering if I should interpret a message differently than I otherwise would
taxilian 13:09 without knowing the message it's hard to speculate
JuanDaugherty 13:09 it's when a solution wide build is in progress
and the VS frame asks if you
want to reload files, with various details
i didn't see anything about this in documentation so was just wondering
taxilian 13:09 that's a cmake thing rather than a firebreath thing; what happens is something has changed with the cmake files and you didn't rerun the prep script
so it reruns cmake for you
which regenerates some files
JuanDaugherty 13:09 rerun the prep script
taxilian 13:09 any time the cmake files change you need to rerun cmake, which is what the prep script does
JuanDaugherty 13:09 by which you mean restart the source line?
taxilian 13:09 by which I mean rerun the prep script so that cmake gets run again
JuanDaugherty 13:09 so it's an update, as would be the case in other make scenarious
?
taxilian 13:09 I'm not sure I understand your question. Cmake runs and regenerates all the project files and other generated files
JuanDaugherty 13:09 re the operative phoneme
lexeme actually
startin to see why some people blow off cmake
I made changes to VS not any of the cmake files
the section of actions here is unclear, but I'm taking a meal break
s/section/sequence/
taxilian 13:09 yes; cmake takes some getting used to
and it's kinda annoying; in fact, using cmake is nearly as annoying as not using cmake
bascially the rule of thumb: don't ever modify your projects directly. Always modify the cmake files insetad
that's just how cmake works
JuanDaugherty 13:09 yeah that doesn't make sense, bbiab
you may wanna think about that for a bit. Use of cmake can't be a reason I can't set VS configuration globally and do a rebuild.
taxilian 13:09 be specific; what are you trying to change?
JuanDaugherty 13:09 it can be a reason to strip out cmake after initial generation of the FB/VS project
just ack a tk failure wrt updating and move on
taxilian 13:09 be specific; what are you trying to change in visual studio that isn't working?
I still don't understand what your problem is
and please keep in mind that I use visual studio to work on firebreath projects all the time wtih no difficulties
JuanDaugherty 13:09 i should be able to change an arbitrary parameter, I should have to notify you
taxilian 13:09 so it may just be something you aren't understanding
JuanDaugherty 13:09 *shouldn't
taxilian 13:09 you can; it just won't be saved. if you want to change a parameter permanently in a cmake project, you change it in the cmake files (*not* the firebreath files, the cmake files in your own project)
it makes perfect sense; you arne't using a visual studio project, you're usign a cmake project
I change things using vs all the time when I'm just doing a quick test; then once I know what I need, I just update the CMakeLists.txt or Win/projectDef.cmake files
JuanDaugherty 13:09 yeah, it looks like the cmake-native build interaction isn't ...
(rhetorical ellipsis)
taxilian 13:09 again, not following you
JuanDaugherty 13:09 got it. So the cmake infrastructure needs a hand edit for any change in VS it looks you're sayin
taxilian 13:09 seperate in your mind VS from project
they aren't the same thing
any permanent change in the project you need to edit in the cmake files
JuanDaugherty 13:09 ur srs?
taxilian 13:09 that's how cmake works
JuanDaugherty 13:09 did you think I was confused about the diff between VC and CMake?
taxilian 13:09 you keep referring to the project settings as "VS" is all
JuanDaugherty 13:09 <- nearly 60, programmer all adult life.
taxilian 13:09 <- not trying to be offensive, trying to understand
JuanDaugherty 13:09 *VS
taxilian 13:09 and believe me… I run into all types here. =]
JuanDaugherty 13:09 no doubt, I've fielded a few for you
taxilian 13:09 hehe
and I appreciate that
it might be worth looking around at how cmake is used in other projects. I'll be the first to admit that our use of cmake isn't as good as it could be, but when you're using cmake it's a bit different than just using native projects
and it can be a little confusing at first
but it's really not nearly as bad as it may seem at first glance
JuanDaugherty 13:09 as an ole dude, I'm so tickled to have survived to a time when I can just read the free fucking source code, it's all gravy and no worries for me
taxilian 13:09 the real problem is that without cmake I'd have to maintain project files and solutions for 3 (soon 4) different versions of visual studio, plus mac (makefiles and xcode) and then linux
JuanDaugherty 13:09 but you know I communicate give feedback if it looks like there are channels
this is all awareness
it can be entirely addressed in English in documentation
taxilian 13:09 believe me; I am well aware of the frustrations with cmake =] I've looked at other options and never found one that wouldn't be even worse
JuanDaugherty 13:09 and of course the has to be mental clarity in the documented doing
taxilian 13:09 and I simply don't have time to write all the docs myself, so docs are updated either when there is something really fundamentally wrong or when users update it :-/
JuanDaugherty 13:09 but Amercian English technical prose at the right target level of presumptive sophistication can be extremely efficient
*there has to be
taxilian 13:09 I suspect that if I really tried I could explain it better
I just don't have time
JuanDaugherty 13:09 *American English
np, the discovery is complete
to a first level
I am not frustrated with cmake, have used it before and don't have any problem with it, gmake, ant, whatever.
in general I don't get frustrated anymore, I think that's one reason a lot of people burn/get out, they don't get ovr that
i mean computing of course, in rl I'm super frustrated
taxilian 13:09 hehe
JuanDaugherty 14:09 still there?
taxilian 14:09 usually
JuanDaugherty 14:09 if you use VS all the time, cmake propagated changes trigger the VS change alerts, how do you in general handle them?
*when cmake propagated
taxilian 14:09 well, first I dont' end up changing the cmake files all that often
when I do, I run the prep script from the command line
so I'm expecting the change alerts
and it's not nearly so annoying because it doesn't interrupt the build
JuanDaugherty 14:09 you don't like set version numbers?
taxilian 14:09 ? version numbers where?
in PluginConfig?
JuanDaugherty 14:09 wasn't asking if you got annoyed, but how you respond in general to the VS requests, y/n?
taxilian 14:09 always yes
JuanDaugherty 14:09 yes, PluginConfig
got it
taxilian 14:09 I only use version numbers in production builds
and those I pass in when I run the prep script on the continuous integration server
so I never commit a version number to source control
or store it in a file
JuanDaugherty 14:09 so you would have the project not loaded in VS, change the version, run the prep script, then load the solution?
taxilian 14:09 I dont' ever "change the version". I have a build script that calls the prep script with a version in it and then builds
if I'm not building on the build server, I dont' care about the version
it's hardcoded to something really high so my upgrade detection code won't go off
JuanDaugherty 14:09 different from 1.0.0.0
taxilian 14:09 and btw if the prep script didn't run it wouldn't copy the version from PluginConfig to the various places it needs to be
here is an example of what I do: https://gist.github.com/3693528
so in the buildscript I define the major/minor/path versions and then use the %BUILD_NUMBER% var from jenkins
taxilian 15:09 FireBreathBot: tell JuanDaugherty you misunderstood my request; I was not asking you not to ask questions or talk in the channel. I don't even mind if you want to complain about my code =] my PM was intended to just ask you not to swear in the channel
FireBreathBot 15:09 taxilian: I'll pass that on when JuanDaugherty is around.
taxilian 15:09 grr
johannes 17:09 oh fun of communication online!