Hopbot log for 2007-08-07 - Helma IRC channel: #helma on irc.freenode.net

2007-08-07:

[21:52] <midnightmonster> I'm finding that I need to make fixes and additions to helma.Mail to keep working. I'm reporting them as bugs as well, but of course I don't know for sure if/when my fixes will be checked in. Any suggestions on the best way to keep track of my changes and avoid losing them later? I don't have a cvs checkout of helma as I don't have cvs or a working java build environment on my dev machine
[21:52] <midnightmonster> (I think cvs is fairly useless for this kind of case anyway--subversion wouldn't be very useful, and afaict it's a superset of cvs)
[22:03] <midnightmonster> actually, having code I depend on that isn't standard and isn't in my source tree (and hence in my publish script) is the main problem atm. would any harm come from copying the helma/Mail.js into my Global folder and dis-including the helma/Mail repository in my application?
[22:25] <doublec> Maybe use something like git?
[22:26] <doublec> Make a git repository of the helma cvs or tarball
[22:26] <doublec> clone that and make your changes from that
[22:26] <doublec> when you update cvs or a new tarball, do it in your git repository
[22:26] <doublec> and pull from that to your modified one
[22:26] <midnightmonster> git's on the list eventually. atm I don't have time for learning a whole new vcs.
[22:27] <midnightmonster> I think just moving it into my application's svn source tree is good enough for now
[22:27] <doublec> it's how I track changes I make to projects where I don't have cvs access (Rhino and firefox basically)
[22:29] <midnightmonster> *nods* it's definitely on the list of things to do/learn. I'm hoping that by the time I get around to it the running-on-Windows story will be cleaner and happier, too
[22:29] <doublec> yeah, that is a bit of a hassle. I use cygwin but apparently the mingw port is coming along nicely, and binaries are available for it now
[22:31] <midnightmonster> but after hearing/reading Linus explain it a few times, it's clear to me that he's pretty much right (as usual) and it's the one I should be using
[22:37] <midnightmonster> unit testing question for anyone who may know: how are you supposed to write a test for a method that principally mutates the object's internal state?
[22:43] <zumbrunn> midnightmonster, what you said sounds reasonable... but instead of just dropping modified module files into your app, you could keep them in a separate repository and include that to your app
[22:44] <zumbrunn> the current mechanism of adding repositories dynamically isn't very ideal in this regard
[22:44] <midnightmonster> ?
[22:44] <zumbrunn> I'm sure we will be able to improve that
[22:45] <midnightmonster> (not sure I understand what should be improved about the dynamic adding of the repositories)
[22:45] <zumbrunn> well, the idea of the app.addRepository('modules/helma/Mail.js') syntax is that there is a standard way of adding library code...
[22:46] <zumbrunn> so, if you are forced to go around that in order to use your custom version of the file, that kind of defeats the purpose
[22:47] <midnightmonster> but as you say I could just make my own repository
[22:48] <zumbrunn> yes, but then your dynamic includes will not point to the standard home of that module file anymore
[22:48] <zumbrunn> again, that's ok... and it's what I would do
[22:49] <midnightmonster> yeah... I think it would be too magical if there was a way that app.addRepository('modules/helma/Mail.js') didn't include the code from modules/helma/Mail.js
[22:49] <zumbrunn> (respectively, you will probably omit the dynamic include)
[22:50] <zumbrunn> yes, but maybe/probably we will come up with a different, more flexible system
[22:51] <zumbrunn> what we currently have is what was reasonably easy to implement at the time
[22:53] <midnightmonster> I keep hearing people complain about the way Java including libs works, or the way PHP including libs works... I have never used a system that people seem to regard as significantly better, and I've never heard a concrete explanation of how to do including libs "well", so I'm not yet very picky about this :-)
[22:56] <midnightmonster> zumbrunn, (new topic) I notice that, e.g., the helma.Mail methods typically return nothing. seems like it would be more useful to return true/false on success/failure or return this like jquery so I could write myMail.setFrom(whatever).setTo(somebody).setText(yadayada).send()
[22:58] <zumbrunn> chaining would be nice :-)
[22:58] <midnightmonster> yeah. I really like chainable methods
[22:58] <midnightmonster> the mail example is a good one in favor of chaining, I think
[23:00] <midnightmonster> (backtracking, right now I have several lib-type things in my global folder. I'll probably organize them properly into a repository or two once I get the first version launched)
[23:18] * midnightmonster just got the potential problem with the current include system
[23:20] <midnightmonster> e.g., if another Helma or Jala lib requires helma/Mail, it will include the standard helma/Mail and mine will disappear
[23:23] <midnightmonster> the behavior there would be improved if the helma.Mail = function... declaration were wrapped in if(!helma.Mail){ }. Then it would still be my responsibility to include my own version ahead of time (when ideally the include would be for "helma.Mail" rather than a file path, and Helma would somehow *know*), but at least my modified helma.Mail wouldn't get clobbered
[23:24] <zumbrunn> your can avoid that by already including the standard module as a repository of your app
[23:24] <zumbrunn> and then overriding it in a custom app
[23:25] <midnightmonster> so, include the standard, then clobber it with mine, so it won't clobber mine later
[23:25] <midnightmonster> that's... special
[23:25] <zumbrunn> the load order of the repositories should already take care of that, yes
[23:25] <zumbrunn> the current system so far seems workable
[23:25] <zumbrunn> but it's not ideal
[23:26] <midnightmonster> yeah, I think that works ok for me.
[23:27] <midnightmonster> but would it still work in my current setup: include the standard mail repo in my onStart function, my modified version is just in Global ?
[23:27] <midnightmonster> I'm thinking no, that my version will get loaded first, then onStart will be called, and mine will go away
[23:28] <zumbrunn> the standard version needs to be included in a repository that loads before your main app repository
[23:29] <zumbrunn> (what you said is correct, I believe)
[23:30] <zumbrunn> after that, it shouldn't be a problem if code dynamically adds the standard repository again
[23:30] <zumbrunn> since Helma wont load it again, if it already has been included
[23:31] <zumbrunn> that's my theory, anyway

 

 

In the channel now:

Logs by date: