[02:34:41] *** mumitr0ll has joined #JNode.org
[03:27:30] *** mumitr0ll has quit IRC
[05:20:51] *** peda_ has joined #JNode.org
[05:28:24] *** peda has quit IRC
[09:20:14] *** tango has joined #JNode.org
[09:33:59] *** tango has quit IRC
[10:46:17] *** alea has joined #JNode.org
[13:03:15] *** Wooden has joined #JNode.org
[13:09:05] *** lsantha has joined #JNode.org
[13:09:18] <lsantha> hello
[13:09:24] <Wooden> hello
[13:10:06] <Wooden> did you get my mail?
[13:10:34] <lsantha> yes, but I didn't want you disturb you while away
[13:10:39] <Wooden> ok ;)
[13:10:47] <lsantha> can we continue now?
[13:11:01] <Wooden> yes
[13:11:02] <lsantha> the nightly builds
[13:11:03] <lsantha> ok
[13:11:53] <lsantha> there are several places on the jnode portal which refer to the nightly builds server
[13:12:05] <lsantha> just 4-5 links
[13:12:23] <lsantha> and they primarily point to www.jnode.eu
[13:12:24] <Wooden> ok
[13:12:37] <lsantha> I have already talked to the owner of the domain, Martin
[13:13:00] <lsantha> and he will make the necessary adjustments too
[13:13:04] <Wooden> ok
[13:13:21] <lsantha> but when he does it everything else should be in place and functional
[13:13:31] <lsantha> so let's start it
[13:13:46] <Wooden> ok
[13:13:49] <lsantha> www.jnode.eu will be the virtual host you need in the httpd.conf
[13:14:17] <Wooden> yes for the moment, while the domain still points to the old server
[13:14:27] <Wooden> we'll use jnode.m00ware.com
[13:14:55] <Wooden> (for testing purpose)
[13:15:05] <lsantha> yes
[13:15:33] <lsantha> the most visible link is the one in the upper left box of the portal
[13:15:44] <lsantha> called build status
[13:15:52] <Wooden> yes i saw that
[13:15:57] <lsantha> http://www.jnode.eu/report-data/nightly-build/log.txt
[13:15:58] <lsantha> ok
[13:16:32] <lsantha> the others are on this page: http://www.jnode.org/reports
[13:16:42] <Wooden> yes
[13:16:46] <Wooden> so basically
[13:16:48] <Wooden> right now
[13:16:49] <lsantha> that's all
[13:17:21] <Wooden> http://jnode.m00ware.com/ is the same than http://www.jnode.eu/report-data/
[13:17:50] <lsantha> ok
[13:17:54] <Wooden> which means that there is
[13:17:57] <Wooden> Javadoc
[13:18:00] <Wooden> plugin doc
[13:18:05] <Wooden> plus build status
[13:18:07] <lsantha> everything is supposed to be in the report-data directory
[13:18:15] <Wooden> (log + icon + status.html)
[13:18:29] <Wooden> yes
[13:19:06] <Wooden> but for exemple the build results (crdom + source snapshot package)?
[13:19:20] <Wooden> it's not available for download?
[13:24:06] <lsantha> we have nighly builds too
[13:24:22] <Wooden> where is it on the website?
[13:24:39] <lsantha> but we don't promote those binaries actively for download
[13:24:54] <lsantha> let me check because I'mnot sure thre is a direct refrence to that
[13:25:09] <Wooden> http://www.jnode.eu/releases/nightly-builds/ ?
[13:25:28] <Wooden> i couldnt find the referance anywhere but in an issue ticket
[13:25:34] <Wooden> http://www.jnode.org/node/1490
[13:26:00] <Wooden> ok so i have to setup that directory too
[13:27:05] <lsantha> yes, that's it
[13:27:27] <lsantha> this is only for exceptional situations
[13:27:53] <lsantha> like when someone cannot access sf
[13:28:22] <lsantha> or especially needs this
[13:28:28] <Wooden> ok
[13:28:44] <Wooden> well that would be a shame to build it and throw it away after anyway
[13:29:32] <lsantha> ok, there is a reference to it here too: http://www.jnode.org/node/25
[13:29:38] <lsantha> just to know
[13:29:52] <lsantha> that is the "Start here!" page
[13:30:37] <Wooden> ok
[13:31:16] <Wooden> ok i launch the script to check that it builds things properly
[13:31:18] <Wooden> ...
[13:31:32] <Wooden> it takes about 10 to 15 minutes
[13:31:44] <Wooden> at least it did so last time
[13:33:41] <lsantha> ok
[13:40:52] <lsantha> Wooden, now I have much better test coverage than last time of the jnode classlib with mauve
[13:41:33] <lsantha> this is the most recent test report
[13:41:35] <lsantha> http://testsuite.jnode.bucksch.org/2009-05-03-11-00/results/
[13:42:08] <lsantha> and so it's safer now to start applying your changes to X86Assembler and jnasm
[13:42:49] <lsantha> could you please the patch to the portal for review?
[13:43:06] <lsantha> just like you did for building the cdrom
[13:43:21] <Wooden> ok
[13:43:55] <lsantha> hoops this was missing above: *send*
[13:44:08] <lsantha> what is the status of that now?
[13:44:52] <Wooden> jnasm?
[13:45:16] <lsantha> basically: getting jnode to boot
[13:45:39] <Wooden> not much new since last time i think
[13:45:43] <lsantha> last time it went pretty far ahead in the boot process but then there was an NPE
[13:45:47] <Wooden> it begins loading plugins
[13:45:57] <Wooden> and crashes with a NPE while doing so
[13:46:03] <Wooden> yes
[13:46:07] <lsantha> that's already well ahead
[13:46:14] <Wooden> as for "how to fix"
[13:46:28] <lsantha> I will try it too
[13:46:34] <Wooden> the last technique i used looked ok
[13:46:49] <lsantha> which was it?
[13:46:50] <Wooden> what i did was a direct diassembly text compare
[13:47:06] <Wooden> of the original and jnasm-created nano kernel
[13:47:23] <Wooden> i spoted some problems in CMP i think
[13:48:17] <Wooden> the only hard thing with this is that before comapring i have to "clean" the diassembly which means NOP-away the various data parts (such as embeded strings or constants)
[13:48:47] <Wooden> which sometimes lead to mis-alignement of instructions and thus confuse the comparison
[13:49:19] <Wooden> but once you've done so it's quick enough to go through the whole diff to spot errors
[13:50:54] <Wooden> i remember there was still this problem with jnasm not handling the FAR moddifier for CALL (even when explicitely specified in the source)
[13:51:34] <Wooden> maybe adding support for the FAR moddifier to CALL would help too
[13:51:47] <Wooden> build is finished btw
[13:51:50] <Wooden> let's see
[13:51:51] <Wooden> ..
[13:52:32] <Wooden> ok the releases folder contains the freshly build iso and src package
[13:52:52] <Wooden> status show a nice greek check mark
[13:53:15] <Wooden> and the log looks ok
[13:53:24] <Wooden> Total time: 9 minutes 9 seconds
[13:53:24] <Wooden> Build ended at Sun May  3 13:48:20 CEST 2009
[13:57:05] <lsantha> excellent
[13:58:27] <peda_> oh hi all
[13:58:43] <peda_> Wooden, have you thought about the image cache?
[13:59:06] <Wooden> nope
[13:59:13] <lsantha> hi
[13:59:27] <Wooden> what should i tell apache?
[13:59:40] <peda_> I'm searching for it on the old server right now
[13:59:42] <peda_> give me a bit
[13:59:47] <Wooden> ok
[13:59:49] <Wooden> thx
[14:00:47] <lsantha> peda_, the other day we talked about the need to move out the classlib binaries from the source control to a place where we could do automatic uploads and downloads started from the build process
[14:01:15] <peda_> yes I remember that
[14:01:33] <lsantha> can you see a solution for that?
[14:01:41] <peda_> # Reduce the time dynamically generated pages are cache-able.
[14:01:41] <peda_> <IfModule mod_expires.c>
[14:01:41] <peda_>   ExpiresByType text/html A1
[14:01:41] <peda_>   ExpiresByType image/png A1
[14:01:41] <peda_> </IfModule>
[14:02:01] <lsantha> ... on your server
[14:02:07] <peda_> Wooden, we have this in our .htaccess,
[14:02:38] <peda_> I think it would be enought to have a similar entry in .htaccess in the directory where status.png is in
[14:02:57] <Wooden> ok i guess this is juset for the status png and html ?
[14:03:04] <Wooden> ok
[14:03:09] <lsantha> peda, if not, it's no problem we can go and ask at the next server
[14:03:24] <peda_> lsantha: I had one idea that might work
[14:03:44] <peda_> but anyway, it needs dedicated user logins, we can not combine it with sf users
[14:04:08] <peda_> so I thought of using git on jnode.org via web dav
[14:04:39] <lsantha> hm, sounds a bit complicated but if you can make it work it's ok
[14:05:14] <lsantha> I think too that we might need to distribute additional credentials for this to work
[14:05:33] <lsantha> to commiters who want to make commits to the classlib
[14:05:49] <lsantha> the download part of it can be more public
[14:05:56] <lsantha> because these are public assets
[14:06:04] <peda_> hmm yeah, which makes git even more attractive
[14:06:05] <lsantha> write permission though is different
[14:06:15] <Wooden> btw
[14:06:40] <peda_> I think I'll make a forum post
[14:06:55] <Wooden> why ot just nightly or hourly build the classlib jar? since there is the classlib dir in the svn repo
[14:07:08] <lsantha> peda_, it would be nice to know when this will be available
[14:07:10] <Wooden> there's no need for a built jar in the svn?
[14:07:17] <peda_> I think the most important thing is, that those that actually work on classlib can access it easily
[14:07:30] <lsantha> this is because opejdk6 b16 has been relesed recently
[14:07:40] <peda_> ok
[14:07:47] <lsantha> and it would be good for me to update the classlib to it
[14:07:56] <peda_> where is it now?
[14:07:58] <lsantha> in principle it shouldn't be much work
[14:07:59] <peda_> still in svn right?
[14:08:04] <lsantha> yes
[14:08:09] <peda_> and would _you_ be ok with git?
[14:08:31] <peda_> which btw means, it can be downloaded with http
[14:08:45] <peda_> you don't need git to get the files, just to modify them
[14:09:13] <lsantha> and it makes a good point in the release notes: "JNode class library updated to OpenJDK6 b16" ;-)
[14:09:22] <peda_> I just want to know if you're ok with that solution before I post to the forum
[14:10:51] <lsantha> well, it's ok what meets the requirements
[14:11:37] <lsantha> which is that: in the classlib6 project we upload from the build (this would be more elegant then by hand)
[14:12:13] <lsantha> and in jnode/trunk the build process will make the download automatically when there is new classlib available
[14:12:19] <lsantha> that all we need
[14:12:43] *** ApoloGod has joined #JNode.org
[14:12:49] <ApoloGod> http://apologod.mybrute.com
[14:13:00] *** ApoloGod has quit IRC
[14:13:08] <Wooden> lol
[14:13:17] <peda_> lsantha: ok
[14:13:19] <lsantha> it would be bad practice to restrict uploading
[14:13:28] <lsantha> to one person, like me
[14:13:37] <peda_> Wooden: well, actually he reached his goal.. he's linked via the irc logs :/
[14:13:44] <lsantha> the current solution doesn't have such restriction either
[14:18:15] <lsantha> peda_, do you want to put it to your server where jnode.org is?
[14:19:05] <peda_> I'm just checking if this could be an option
[14:19:06] *** Stephen_Crawley has joined #JNode.org
[14:19:11] <peda_> hi Steve
[14:19:13] <Stephen_Crawley> Hi guys
[14:19:26] <lsantha> I hope uploading and downloading the 35MB will not harm the jnode.org user experience on jnod.org
[14:19:31] <lsantha> hi Steve
[14:19:49] <Stephen_Crawley> I was reading the discussion on the IRC log about the classlib binaries ...
[14:20:02] <lsantha> yes?
[14:20:09] <Stephen_Crawley> Umm ... before you actually make tje change, ....
[14:20:39] <Stephen_Crawley> Can we try an experiment to see whether the dowload times are significantly impacted???
[14:21:12] <lsantha> the download times from jnode.org?
[14:21:22] <Stephen_Crawley> I understand that it is proposed that they be downloaded from EU
[14:21:27] <peda_> hmm well, what I had in mind was writing a forum post.. but now I'm confused
[14:21:30] <Stephen_Crawley> Yes ...
[14:22:08] <lsantha> peda_, there is a thread about this
[14:22:12] <lsantha> let me see
[14:22:13] <Stephen_Crawley> OK.  That's a good plan.  (I was skimming the logs)
[14:22:17] <peda_> so, just that I get this straight: the idea was/is, that we move the classlib to another place to get faster download speads over sf?
[14:22:43] <lsantha> peda_, the idea is to move out the binaries from svn
[14:23:17] <lsantha> because they are overloading the sourcecontrol system
[14:23:26] <peda_> ok, well, Steve, do you want to test the speed? I can put you a large file to the server...
[14:23:29] <Stephen_Crawley> That is correct
[14:23:33] <lsantha> more exactly the disk space required by it
[14:23:41] <peda_> ok, I see
[14:23:50] <lsantha> on fs there is no limit
[14:23:56] <lsantha> but they might complain
[14:24:05] <Stephen_Crawley> Can I suggest an alternative approach?
[14:24:13] <lsantha> however I'm pretty sure this will actually bite ourselves much earlier
[14:24:16] <lsantha> so we will complain
[14:24:21] <peda_> sure Steve, what?
[14:25:13] <Stephen_Crawley> I was wondering if it would be better to expect developers to checkout 'classlib6' and do the builds themselves
[14:25:34] <lsantha> well, I have been thinking about that
[14:25:58] <peda_> I wouldn't mind .. but wasn't the original idea to get shorter build cycles?
[14:26:03] <Stephen_Crawley> That avoids monster downloads ... and binaries in SVN
[14:26:05] <peda_> or isn't that the case anyway
[14:26:07] <lsantha> imho that would greatly lower the advantages of having separate project for the two
[14:27:08] <lsantha> two whole point of the classlib separation was to make the life of the majority of jnode developers easier
[14:27:51] <lsantha> by saving them the extra work of dealing with the huge sourcecode tree what the classlib is
[14:28:07] <Stephen_Crawley> Hmmm ... I guess it depends whether a classlib rebuild is faster than a 35Mb download
[14:28:30] <cluster_> you dont have to download on _every_ clean rebuild though
[14:28:42] <lsantha> cluster_, that's right
[14:28:57] <lsantha> I have avoided it from the very beginning
[14:29:03] <cluster_> the benefit i get is now its a 5 min build, instead of a 20 minute build
[14:30:06] <Stephen_Crawley> I think you might find that a significant part of those 20 minutes are in building the pack200 file, etc
[14:30:25] <cluster_> no, it was in building core
[14:30:27] <lsantha> Steve, the reduction of the source code in jnode/trunk is very significant with the separation of the classlib
[14:30:31] <cluster_> too much memory requirement
[14:30:49] <cluster_> my system starts using the swap drive to build core, and there's little i can do about it
[14:30:52] <Stephen_Crawley> How much memory do you have to build with?
[14:31:10] <cluster_> 1.5gb if i completly shut down everything
[14:31:17] <lsantha> I don't remember the exact numbes now but they are some like: 20K source file before and 5K after
[14:31:24] <cluster_> but a core build could take over 1.5gb easy
[14:31:33] <Stephen_Crawley> (You are speaking to someone who just went out an bought 4Gb :-)
[14:31:56] <cluster_> but there's another side to that too
[14:32:07] <lsantha> Steve, actually I have good new for you
[14:32:13] <cluster_> i might have enough ram to build jnode, but it wipes my OS file cache to do so
[14:32:30] <lsantha> there is an empty target in the clsslib6: quickdeploy
[14:32:31] <cluster_> and that slows everything down because it has to re-cache everything again
[14:32:55] <cluster_> i actually had another idea on how to do this with lightweight downloads
[14:33:03] <cluster_> like < 100kb downloads
[14:33:12] <lsantha> there will be the target for myself basically and for those who prefer to have the classlib6 tree and the jnode/trunk three side bye side
[14:33:36] <lsantha> I'm among them, for sure
[14:34:10] <cluster_> so you'd have a choice, build classlib, or use the jar
[14:34:23] <lsantha> and while I'm trying to make the live of the majority of jnode developers easier I care to not make my life much harder
[14:34:48] <Stephen_Crawley> Here's an idea to make that (two ways) idea work.
[14:34:57] <lsantha> Steve, the quickdeply is for this case, I just should finish it
[14:35:38] <lsantha> also we have the option to use the build properties for cutsomization
[14:35:39] <Stephen_Crawley> (Sorry forget that ... I'm still thinking svn dowloads.)
[14:36:17] <Stephen_Crawley> Yes I think I can see how that would worke Levente
[14:37:11] <Stephen_Crawley> I'd deploy classlib and jnode side-by-side too.  Infact I already have.
[14:37:49] <lsantha> yes, that's a good idea for advanced users (=developers)
[14:38:06] <Stephen_Crawley> If we offer the developers the two choices, they can decide which works best for them.  That is good.
[14:38:15] <lsantha> that's it
[14:38:44] <Stephen_Crawley> OK ... I'm happy with that.
[14:38:57] <lsantha> when you have them side by side all is needed is copying two files from one dir to the other
[14:39:10] <lsantha> classlib.jar and classlib-src.jar
[14:39:15] <lsantha> it's that simple
[14:39:23] <Stephen_Crawley> It might be worth doing that experiment though to make sure that jnode.org can handle the extra downloads
[14:39:33] <lsantha> I think so too
[14:40:03] *** Wooden has quit IRC
[14:40:13] <Stephen_Crawley> Question: do you have network / dowload quotas on the machine ... from your ISP?
[14:40:22] <peda_> how do you want to get the classlib(-src).jar to the server?
[14:40:31] <lsantha> mine is unlimited
[14:40:43] <peda_> 1000GB / month.. if I exceed that they limit my line to 10MBit
[14:41:17] <lsantha> peda_, in that form they are huge
[14:41:30] <Stephen_Crawley> I was actually meaning for the "jnode.org" machine.
[14:41:37] <peda_> right now on release days we get up to 5GB peak day
[14:41:41] <lsantha> but I crompress them for network trips
[14:41:54] <peda_> Steve, yes, I was speaking for jnode.org
[14:42:01] <Stephen_Crawley> Peda, can I move to Germany? :-)
[14:42:23] <peda_> Steve and all, the problem with this PC is just that I can not give anyone a shell
[14:42:54] <lsantha> peda_, we could ask wooden too
[14:42:59] <lsantha> if you don;t mind
[14:42:59] <peda_> so we need something else that satisfies anyone and gives enought freedom for remote admin,..
[14:43:05] <peda_> no I don't mind
[14:43:32] <lsantha> his server would be also very suitable because it's a hosted server not a homebased one
[14:43:45] <lsantha> and this is something that requires high availablity
[14:43:57] <peda_> hmm no, I think we mistook each other
[14:43:58] <peda_> ...
[14:43:59] <lsantha> possibilly as high as sf itself
[14:44:15] <lsantha> why?
[14:44:22] <Stephen_Crawley> Yes I see the problem.  If we stick with SourceForge then we don't have to create committer FTP (or whatever) accounts
[14:44:26] <peda_> or not?! well anyway, jnode.org is a server in a big data center
[14:44:35] <peda_> not at home or something like that..
[14:44:41] <lsantha> peda_, I know
[14:44:50] <peda_> ok
[14:44:50] <lsantha> I was implying the other options
[14:44:54] <Stephen_Crawley> I didn't though ...
[14:44:58] <lsantha> which is Ben and Petri
[14:45:05] <lsantha> those are home based servers
[14:45:16] <lsantha> and we spare them for running testsuits
[14:45:21] <peda_> yup ok
[14:45:37] <lsantha> not as critical as the other services
[14:45:55] <peda_> though for they will probably not be good for the big downloads, in case thats is implied with the classlib.jars
[14:46:32] <lsantha> 35M is the combined size to uplod and download for the two
[14:46:59] <lsantha> we should see then what Wooden says
[14:47:12] <peda_> yeah
[14:47:30] <Stephen_Crawley> Perhaps we should consider something like Amazon S3
[14:47:56] <peda_> so what I could and would provide is a git repo for the classlibs and I'd ask cluster in the same time to move his git repo to jnode.org to combine that
[14:48:20] <lsantha> Stephen_Crawley, regarding sf, uploading there big files like when doing a release is pretty hard, sf is no good for this
[14:48:22] <peda_> otherwise I'm happy too if wooden hosts it in some way
[14:48:57] <lsantha> Stephen_Crawley, that's why we try to find our way
[14:49:30] <Stephen_Crawley> Levente ... I said >>Amazon<< S3, not SourceForge
[14:49:33] <cluster_> peda_, if you do that, can you link the jnode.org username to the git repo? and have a page setup on the user page to upload an ssh key
[14:49:55] <Stephen_Crawley> But the GIT idea sounds promising
[14:49:59] <cluster_> otherwise ssh keys will have to be entered by hand
[14:50:01] <lsantha> Stephen_Crawley, sf was a resonse for your comment above, sorry
[14:50:19] <lsantha> regardin S3, is it free?
[14:50:22] <lsantha> :-)
[14:50:25] <peda_> hmm yes, that is a good idea cluster
[14:50:37] <Stephen_Crawley> I don't think so ... but I think it is cheap
[14:50:44] <cluster_> then you dont have to do git over webdav either
[14:50:45] <peda_> the only thing.. I have to talk with the co-owner about that, webdav would have been easier
[14:51:00] <Stephen_Crawley> I'll go over and see if I can find out.
[14:51:10] <peda_> cluster_: but I'll ask.. sounds like a good idea
[14:51:30] <cluster_> im not sure by how much, but webdav isn't as 'effecient' as the git protocol
[14:52:07] <peda_> well, I assumed the fully "tunnel" the git protocol, but indeed I never checked that
[14:52:19] <lsantha> imho, we do not need versioning for this
[14:52:34] <lsantha> so versonconrol systems can be an overkill
[14:52:39] <cluster_> for classlib?
[14:52:48] <cluster_> im pretty sure he's talking about the sources
[14:52:50] <lsantha> for the binaries
[14:53:08] <lsantha> for the binaries that we want to upload and download
[14:53:13] <cluster_> no you wouldnt use git for that, use ftp
[14:53:28] <lsantha> yep, ftp, rsync..... etc
[14:53:47] <lsantha> whatever is easier on the server
[14:53:56] <cluster_> peter was talking about the sources
[14:54:00] <lsantha> ok
[14:54:44] <cluster_> peda_, whats wrong with where it is? its free bandwidth, and that includes tar-ball downloads of any revision
[14:54:44] <Stephen_Crawley> FYI: Amazon S3 pricing - http://aws.amazon.com/s3/#pricing
[14:55:08] <peda_> cluster_: nothing.. just the domain name :)
[14:55:10] <lsantha> cluster_, so you basically say that if we use git for the classlib then there is no need to move out the binaries?
[14:55:54] <cluster_> you still probably dont want git versioning the binaries
[14:55:55] <cluster_> but
[14:55:57] <lsantha> I'm a bit confused, sorry
[14:56:02] <lsantha> ok
[14:56:05] <lsantha> understood
[14:56:19] <lsantha> so you only plan to have the classlib6 in git too
[14:56:23] <lsantha> not inly in svn
[14:56:43] <cluster_> im pretty sure thats what he meant
[14:57:14] <lsantha> that's ok, it's convenient for the early adopters of git
[14:57:34] <cluster_> you could probably do both in the same repository actually
[14:58:47] <cluster_> there are git 'submodules' which are designed specifically for this type of situation
[14:59:27] <lsantha> and how would svn cope with it?
[14:59:55] <cluster_> with submodules? im not totally sure, i haven't looked that far into them yet
[14:59:55] <Stephen_Crawley> Cluster - for those folks who want to avoid downloading the binaries ... they need to be not in the 'jnode' tree.  Is that what you had in mind?
[15:00:36] <cluster_> steve, to do that, just dont have them tracked, put the binaries in the ignore files
[15:00:44] <cluster_> and git/svn will disregard them
[15:01:24] <cluster_> and if the developer has his build configured to download binaries
[15:01:42] <cluster_> then building will check if the binaries have changed
[15:01:57] <cluster_> i believe http can tell you the file mtime
[15:02:30] <cluster_> when someone uploads new binaries, the build will find the new mtime and download them, if they have it configured that way
[15:02:52] <peda_> yeah or add a timestamp file with small size :)
[15:03:19] <peda_> and one thing I wonder.. why do we need to upload the binaries at all? can't we autogenerate them in case of changes + the timestamp file?
[15:03:31] <cluster_> well, you make a local timestamp file that has the mtime of the last time it downloaded
[15:03:45] <cluster_> wget has options for this i believe, but windows wont have that
[15:04:10] <peda_> cluster_: the timestamp file on the server is for the case http does not support mtime ;)
[15:04:24] <cluster_> oh it does
[15:04:26] <cluster_> it has to
[15:04:30] <cluster_> for caching servers
[15:04:35] <peda_> right
[15:05:05] <cluster_> ftp does too, which might be better than http for resume
[15:05:39] <peda_> and what about autobuilding the jars, is there a reason not todo that?
[15:05:41] <cluster_> if the developer does not have a big download pipe, restarting a 35mb download that was at 90% and died can be a pain
[15:06:25] <Stephen_Crawley> Peda ... I think that the problem is people with not enough memory to build classlib quickly
[15:06:46] <peda_> Stephen_Crawley: I mean, autobuilding on the server
[15:07:05] <peda_> i.e. why do we need to upload the jars?
[15:07:08] <cluster_> right
[15:07:14] <cluster_> use a commit hook
[15:07:16] <Stephen_Crawley> Oh ... interesting idea.  But what if it doesn't work sometimes?
[15:07:17] <lsantha> cluster_,  I think it's not possible develop jnode bellow a certain level of hw/bandwith resources
[15:07:42] <cluster_> steve, you mean if the build breaks?
[15:07:47] <cluster_> or what?
[15:08:09] <peda_> so what.. leave the old jars on the server :)
[15:08:31] <cluster_> no, that would throw jnode/trunk and classlib out of sync
[15:08:42] <cluster_> if there were changes to both that were dependant
[15:08:51] <peda_> well.. if classlib doesn't build..
[15:08:58] <Stephen_Crawley> That's what I meant cluster.  Either because the checkin was bad, or because of some mysterious problem that requires someone to login to the box and fix.
[15:09:01] <peda_> it will not build for both cases..
[15:09:24] <Stephen_Crawley> It is the latter case that is more worrying.
[15:09:26] <cluster_> your right, no matter what you do, you still need a backup plan
[15:09:44] <cluster_> and that backup plan is the ability to manually upload if all else fails
[15:09:46] <peda_> well, we might add a empty dummy jar in that case
[15:09:51] <peda_> to _make_ the build fail
[15:10:11] <lsantha> I think the activity in the project will be devided between trunk and classlib6 like 90% vs. 10%
[15:10:20] <lsantha> or a better figure in the favor of trunk
[15:10:34] <lsantha> so we should optimize for that
[15:10:34] <cluster_> right, classlib wont change that much
[15:10:43] <Stephen_Crawley> Personally, I think that it is better to not try to automate this too much
[15:11:11] <peda_> well, the good thing imho would be, it is no real automation
[15:11:14] <lsantha> I'be been doing the uploads by hand so far
[15:11:23] <lsantha> manually
[15:11:30] <peda_> as actually the same thing happens as when e.g. levente takes the source directly
[15:11:36] <Stephen_Crawley> I have done one too.  It was no great problem.
[15:11:39] <lsantha> but there should be automation on the download side
[15:11:55] <cluster_> having a 'build upload' target in classlibs build is all you really _need_
[15:12:08] <lsantha> for sheer usability reasons for the most of us
[15:12:43] <lsantha> 90% vs 10% also shows were automation is a must
[15:12:55] <Stephen_Crawley> Actually, it was no great problem ... without that cluster :-)
[15:13:28] <Stephen_Crawley> Levente is right.  Optimize the common case
[15:14:05] <lsantha> so I think the next step hear is to talk to Wooden
[15:14:14] <lsantha> because that is a free service
[15:14:30] <lsantha> the next in the list...?
[15:14:33] <lsantha> I'm not sure yet
[15:14:45] <cluster_> i got a question
[15:14:56] <lsantha> S3 or we try to find an other donnation
[15:14:58] <cluster_> why does BufferedInputStream require permissions to be instantiated?
[15:15:23] <Stephen_Crawley> That sounds like a bug cluster
[15:15:30] <lsantha> yes
[15:15:33] <Stephen_Crawley> That sounds like a bug ... cluster :-)
[15:15:39] <cluster_> its a RuntimePermission accessDesclaredMembers
[15:15:46] <lsantha> I know there was an issue for that
[15:16:15] <cluster_> i have an issue open for RuntimePermission  getenv
[15:16:26] <cluster_> which may or may not be related
[15:16:44] <cluster_> but steve wasn't able to reproduce it, which is confusing
[15:16:45] <lsantha> it maybe be a very similar issue
[15:16:46] <Stephen_Crawley> I was looking at that ... but it was assigned to you, so I left it :-)
[15:16:57] <cluster_> was it?
[15:17:13] <Stephen_Crawley> We need to see if other people can reproduce it.
[15:17:16] <cluster_> no, thats the Isolate issue thats assigned to me
[15:17:26] <cluster_> thats a different issue
[15:17:28] <Stephen_Crawley> Oh sorry ... you are right.
[15:17:34] <cluster_> isolates are simply not able to access env vars
[15:17:53] <cluster_> but thats something else
[15:18:20] <lsantha> that is because the isolate has its own system properties
[15:18:21] <cluster_> it would be nice to see if someone else can reproduce that
[15:18:22] <Stephen_Crawley> That's probably due to something not being implemented.
[15:18:44] <Stephen_Crawley> Levente we are talking about getenv, nor getProperties
[15:18:46] <lsantha> so when you want to set or get the system properties in the common way it will not work
[15:18:50] <Stephen_Crawley> (not)
[15:18:53] <cluster_> not properties
[15:18:59] <cluster_> props work
[15:20:00] <Stephen_Crawley> This has probably because the "getenv" variables weren't set by anything until very recently
[15:20:27] <Stephen_Crawley> Now they are used for (bjorne) exported shell variables.
[15:20:47] <cluster_> right, i can export env variables
[15:20:49] <cluster_> and i can echo them
[15:21:12] <lsantha> ok,sorry for the confusion
[15:21:17] <cluster_> which means bjorne is accessing System.getenv() right ?
[15:21:33] <Stephen_Crawley> So ... when Levente did the isolate work he overlooked getenv ... understandably
[15:22:20] <lsantha> actually I doubt System.getEnv was used at all untill very recently
[15:22:31] <Stephen_Crawley> Cluster ... um actually no, I think.
[15:22:45] <lsantha> Stephen_Crawley, getenv vars should be isolated assets
[15:22:47] <lsantha> or not?
[15:23:01] <lsantha> so they fall in the same class as sys properties
[15:23:21] <lsantha> the jvm usually inherits the values from the os at startup
[15:23:25] <Stephen_Crawley> It creates stuff in a child proclet's env, but it doesn't read getenve when it starts.
[15:24:21] <cluster_> what about when expanding env vars on the command line? thats all done without getenv?
[15:24:34] <Stephen_Crawley> At the moment we cannot really create a real "child shell" from another one ... so the problem doesn't arise.
[15:25:00] <Stephen_Crawley> The shell keeps its own copy of the variables.
[15:25:33] <Stephen_Crawley> The problem is that th Java APIs don't allow you to >>change<< what's in the getenv map.
[15:25:48] <cluster_> right
[15:26:44] <cluster_> but that doesn't explain whats up with why I'm getting a RuntimeException for them, with no 'due to some.Class' in the exception
[15:27:11] <Stephen_Crawley> We first need someone else to reproduce the problem.
[15:27:29] <lsantha> I'm afraid I'm not familiar enough with this topic and especially the problem you detected in System.getEnv() when you set isolate invoker
[15:27:40] <lsantha> cluster_, can you point me to the issue?
[15:27:46] <cluster_> ya one sec
[15:27:57] <cluster_> http://www.jnode.org/node/3002
[15:28:09] <cluster_> and this is with the proclet invoker
[15:28:11] <lsantha> thanks
[15:29:05] <lsantha> cluster_, that looks to me an issue with permissions
[15:29:16] <lsantha> how is it related to isolates?
[15:29:37] <cluster_> its not, the two issues got confused above
[15:29:54] <Stephen_Crawley> Levente ... getenv versus isolates is a different issue.
[15:30:07] <peda_> I have to ask for clarity about the original topic: we have a probable solution now and levente, you'll ask Wooden about hosting the jars, so I don't need to do anything?
[15:30:16] <lsantha> yes, I was asking for its description if there is
[15:30:46] <lsantha> peda_, that's right
[15:30:53] <peda_> ok good, as I have to leave
[15:30:54] <peda_> bbl
[15:30:55] <peda_> cu
[15:30:57] <lsantha> cu
[15:31:15] <cluster_> the linked issue is not concerning isolates, see post #2 i show the two exceptions im getting
[15:31:20] <cluster_> the first is the expected
[15:31:23] <Stephen_Crawley> Bye Peter
[15:31:28] <cluster_> the second is the unexpected
[15:31:51] <Stephen_Crawley> The issue about getenv versus isloates is http://jnode.org/node/3001
[15:32:55] <Stephen_Crawley> ... but that's not the one we are talking about now.
[15:33:20] <lsantha> Stephen_Crawley, thanks & understood
[15:33:28] <cluster_> the permission issue was not reproducible by steve, but i get it all the time
[15:33:47] <cluster_> we were hoping someone else could try and reproduce
[15:33:49] <lsantha> I wonder how can you guys have two different results at 3002
[15:34:06] <Stephen_Crawley> So do we :-)
[15:34:12] <lsantha> sorry, phone
[15:34:16] <lsantha> I will check it
[15:35:27] <cluster_> about the BufferedInputStream, is that a known bug?
[15:35:53] <Stephen_Crawley> How are you instantiating it?
[15:36:08] <cluster_> new BufferedInputStream(stdin);
[15:36:33] <cluster_> the stack trace is like 40 methods deep, it goes _way_ deep into jnode
[15:36:40] <Stephen_Crawley> How do you get stdin?  What kind of stream is it?
[15:36:54] <cluster_> oh, getInput().getInputStream()
[15:37:01] <cluster_> or new FileInputStream()
[15:37:07] <cluster_> either way it fails
[15:37:25] <Stephen_Crawley> That's a new one I think.  I've never seen that
[15:38:02] <Stephen_Crawley> Can you see where the access call is happening?
[15:38:21] <cluster_> one sec, i'll boot the broken build i have
[15:41:23] <cluster_> java.util.concurrent.atomic.AtomicReferenceFieldUpdaterImpl.<init>
[15:41:32] <cluster_> is the originator of the access exception
[15:42:27] <cluster_> which is called from the BufferedInputStream constructor
[15:42:35] <Stephen_Crawley> Ouch ... that could be tricky.
[15:42:59] <Stephen_Crawley> I'll see if I can reproduce it.
[15:43:27] <cluster_> should be able to stick new BufferedInputStream(getInput().getInputStream()) in any command
[15:44:20] <cluster_> this is also in the execution path of the SoftByteCodes.allocObject() call
[15:45:46] <cluster_> which ends up calling VmType.doinitialize, on the BufferedInputStream, which catches the security exception and throws the ExceptionInInitializerError
[15:46:35] <cluster_> so it hasn't even returned from the mm with the allocated object, let alone called the constructor
[15:49:37] <cluster_> the actual access check is done by java.lang.Class.checkMemberAccess
[15:51:00] <Stephen_Crawley> I can reproduce it.
[15:51:30] <Stephen_Crawley> We may need to add a doPrivileged around something.
[15:51:59] <cluster_> in the AtomicReferenceFieldUpdateImpl constructor perhaps
[15:52:07] <Stephen_Crawley> This is no the kind of thing that should need an application to be granted permissions.
[15:52:17] <cluster_> no i didnt think so
[15:52:22] <Stephen_Crawley> Need to look.
[15:58:59] <Stephen_Crawley> No ... it needs to be in BufferedInputStream itself I think.
[15:59:14] <cluster_> im just looking at that too
[16:00:07] <cluster_> the buffered output stream doesn't have the same atomic updater
[16:00:19] <Stephen_Crawley> Actually, this looks like it might be an OpenJDK bug.  It would show up if someone tried to instantiate a BIS in an applext sandbox I think
[16:01:07] <Stephen_Crawley> I'll have a go at fixing this ...
[16:01:53] <Stephen_Crawley> Bye for a bit ...
[16:02:01] <cluster_> ok, cya
[16:02:31] *** Stephen_Crawley has quit IRC
[17:07:51] *** Stephen_Crawley has joined #JNode.org
[17:07:59] <Stephen_Crawley> Hey cluster_
[17:08:22] <Stephen_Crawley> The bug fix is checking in.
[17:09:26] <Stephen_Crawley> Its done.  I'm off to bed now.
[17:09:40] *** Stephen_Crawley has quit IRC
[17:21:37] <lsantha> cluster_, now this was a long phone call
[17:22:19] <lsantha> could you test the fix from Steve for 3002?
[17:22:23] <lsantha> Is it ok?
[17:23:51] <lsantha> and now I have to leave
[17:25:28] <lsantha> see you
[17:25:31] *** lsantha has left #JNode.org
[19:07:17] *** tango has joined #JNode.org
[19:25:32] <tango> alea : do u know which is matured library for solving nonlinear equations ?
[19:43:17] *** tango has quit IRC
[21:05:52] *** mumitr0ll has joined #JNode.org
[21:08:55] *** mumitr0ll has quit IRC
[21:12:48] *** lsantha has joined #JNode.org
[21:38:03] *** lsantha has left #JNode.org

top