Log of the 3rd meeting
grover> By popular request we're doing our 3rd MOSA project meeting.
22:02 < rootnode_> ok, ready to start
grover> I posted a topic list for discussion at http://www.codeplex.com/mosa/Thread/View.aspx?ThreadId=42938&ANCHOR#Post142953
22:02 < tgiphil> hi all
22:03 < zMooTh> hi
grover> I have been busy with personal things the last two weeks - actually its been more like my kid & wife doing my daily schedule
grover> I'm certain most of you know what that means :)
grover> anyways, the compiler has been making steady progress again since the last meeting
grover> we've accomplished to create our first bootable images
22:04 -!- Boddlnagg1
has joined #mosa
grover> and we're emitting binaries in PE and ELF
22:04 < Boddlnagg1> re
grover> from my point of view there's a couple of blocking points to call the current state an alpha
22:04 < Boddlnagg1> my wlan crashed -.-
22:05 < rootnode_> ok, ELF is not quite ready yet
22:05 -!- Boddlnagg
Nick collision from services.
22:05 -!- Boddlnagg1 is now known as Boddlnagg
grover> the primary blocking point is our lack of proper register allocation
grover> I'm working on this now and it is my top priority
grover> to get this working in the coming week
grover> I hope this won't touch a lot of code outside of the allocators itself
grover> The other blocking point I see for going to alpha is completing test coverage
22:06 < rootnode_> despite the register constraints :)
grover> the register constraints are a difficult thing, I've been redesigning them... I think the way they're right now doesn't really help... :(
grover> the problem is that they say yes/no to each operand individually, but not for the whole instruction
22:08 < rootnode_> that's quite a problem, yes
grover> the problem comes from the fact that the register allocators have to do two things actually: Move as much operands to registers without violating the .NET memory access guidelines and the other thing is they have to do instruction
grover> e.g. on x86 most instructions can do reg, reg operands, but none is able to do mem, mem
grover> so the register allocator or an instruction selection stage after it has to resolve the latter ones with temporary registers
grover> in order not to introduce stupid spills, I'm right now pursuing the path of doing instruction selection and register allocation in one step as we have the reg lifetimes and uses available there and are able to make better selections
if we can model the instruction constraints as a whole
grover> this may be a mistake later down the road, but it will get us to at least 0.2
22:11 < rootnode_> hm
22:12 < rootnode_> that's a problem. take the easy path to get to 0.2, or take the hard path and make our lifes easier later on?
grover> I see it as an x86 exclusive problem. We could treat x86 like a RISC platform, where all instructions (except load/stores) only operate on registers.
grover> The point here is that we're maybe using 10% of the x86 operand encodings. We're not using SIB at all, and we're not using any advanced encodings.
grover> However we may want to make use of these sometime in the future in order to produce faster code on x86.
grover> I don't see it as taking the easy way to 0.1/0.2, but as to gain some experience with these things.
22:15 < rootnode_> ok, agreed :)
grover> I'd like to create a schedule for optimization stages once we have real code to test the performance on
grover> So if we figure out that this model doesn't give us enough to work with, we can adapt later on.
grover> Test coverage: What bothers me there is that we don't have a whole lot of pointer/reference tests.
grover> We must improve there, especially with pointer arithmetics, in order to get to 0.1
grover> I'd like to propose the following things from the compiler side to go to 0.1:
grover> 1. Finish register allocator(s)
grover> 2. Complete the test coverage
grover> 3. Call it 0.1 alpha 1
22:17 < Z98> or a CTP
grover> 4. Start fixing bugs displayed by the test coverage
grover> and keep releasing alphas bi-weekly until we're down to 0 bugs found by existing tests
22:19 < rootnode_> votes?
grover> 5. Once we've hit the 0 bug mark, release the first beta - again with bi-weekly iterations until there's no more regressions
grover> 6. Make the 0.1 release
> It'd be preferable to not use terms such as CTP, FCS, etc. This sort of technology will be, by inference, fighting upstream against claims of MS-alignment.
22:20 < rootnode_> ack on my side
grover> yes, I'm not happy with CTP as this is not a preview
grover> we could adopt Apple-style verison numbers: 01A1
grover> 01A2, ..., 01B2, ...
grover> But actually I don't care that much about the naming.
22:21 < tgiphil> 0.0.1, 0.0.2, etc. works for me.
22:21 < rootnode_> I'd propose 0.1.rc-number.build-number?
22:22 < rootnode_> release candidate
> Can you ensure the 0.1 feature set wiki page is updated, at least from the available features to be used in code that is to be compiled by the compiler? I noticed the other day non-local variables are not yet supported.
22:23 < Z98> hmm, let's avoid using terms like RC until we actually get to RC level of completeness
grover> Have you seen this page: http://www.codeplex.com/mosa/Release/ProjectReleases.aspx?ReleaseId=19699
grover> I agree not to use the release candidate notion for this (yet)
22:24 < rootnode_> yes, non-local variables still have bugs
22:24 < rootnode_> ok, release candicate was just a "keyword"
22:25 < rootnode_> 0.1.(alpha | beta)-number.build-number
22:25 < rootnode_> sounds better now? :)
grover> ok, I'll agree with that.
grover> Are there any votes against going the route I outlined above?
22:26 < Z98> nope
22:26 < Z98> it's pretty much you and rootnode_ that is doing compiler stuff, and he seems to agree
22:26 < rootnode_> I agree
22:26 < tgiphil> ditto, you got my vote.
grover> rootnode_, anything else?
22:27 < rootnode_> I'd add at least static variables to the list, but as we have tests for it in the list they're already covered
22:27 < rootnode_> but let's still make a formal vote
22:27 < rootnode_> ack on my side
22:28 < tgiphil> I'd like static variables included too.
22:28 < rootnode_> then we could make a more usable hello world sample :D
grover> They're in the feature set of 0.1
> (I only bring up static vars as it would look more impressive for hello world to be refactored into a safe Main, using a private unsafe write method, IMO)
22:28 < rootnode_> using whole classes would be too much for 0.1
grover> we're not even close to that yet
22:28 < rootnode_>
: that's exactly the reason
22:29 < rootnode_> I know, I know
22:29 < zMooTh> let him dream of it ;)
> Next! :o
grover> ok, if there's nothing else on the compiler side of things, I'd like to move to device drivers.
22:29 < rootnode_> tgiphil: your turn now ;)
grover> tgiphil, any news there?
22:29 < tgiphil> As you can see lately, the device driver attributes have recently been removed. This was not because we don't want them (we do in the long run), but because in the short-term it is unlikely we will have the necessarily library support
for attributes, types, and dynamically creating objects given just their type. I'm also trying to get the drivers to work on Cosmos - which at this time does not supp
22:29 < tgiphil> ort attributes.
grover> library support is there for most of it
grover> the only thing that we don't have is the dynamic creation of types by name/type object
22:30 < tgiphil> We'll need mscorlib. I don't think anyone is working on that. ?
> I tend to agree. Reflection and such will come naturally very quickly after the implementation of non-static objects
grover> I'm talking about the stuff that's more lower-level than mscorlib/reflection.
> Wasn't there agreement previously to simply try and HAL-shim Mono's lib?
grover> yes and no
grover> We will still try to do so, but I don't see how the active contributors can do this.
grover> IF we want to do this, we really need some more active coders.
grover> The other option would be to stay below the standard libraries as long as possible.
> I don't mind eventually doing it, once we get to a framework support point that it makes sense to start. I've got most everything dealing with MethodImplAttribute.InternalCall mapped out
22:32 < rootnode> copton
22:33 < copton> rootnode
: pong :-)
22:33 < tgiphil> I'll also help with Mono and implementing those InternalCall methods.
grover> The compiler has the internal call resolution already, so this should be doable.
> We're just back to reflection and non-static assignment
> s/assignment/references... you know what I mean
grover> hehe yes
22:34 < rootnode> copton
: if you know any coders that are willing to code C#, bring'em here ;)
grover> The plan is to have value types (structs) in 0.3
grover> and objects in 0.5
grover> 0.2/0.4 should be quickly following stabilization/refactoring releases
> I have/had/somewhere a writeup on the role of the mosaVM, relating to an implementing OS (e.g. who does what). I have to go find that.
> Most of you know I constantly am concerned about MOSA becoming its own "reference OS" of sorts. :)
22:36 < tgiphil> ^ I'd like to read that.
grover> ^ me too
grover> anyways btt
> Ach... Found the old copy. Have to rewrite it. It's mostly from the POV of an OS's boot process (guess which OS?), rather than from MOSA-VMs POV
grover> tgiphil: How's Cosmos integration coming along?
22:38 < tgiphil> The Cosmos compiler attempts to draw in the whole mscorlib and eventually crashes.
grover> so it should work, but doesn't due to bugs in their code base?
22:40 < copton> rootnode
: I need an introduction. How can I help you?
22:40 < tgiphil> no, the Cosmos compiler just compiles what it needs.
22:40 < tgiphil> but somehow there an "include" that bring in too much.
> Does Cosmos leadership show any inkling of wanting to work with us? Or are we just taking advantage of the license? :D
22:41 < tgiphil> Sorry, I don't have my notes on it right now, it's some international/unicode stuff.
22:41 < rootnode> copton
: ok, wait a sec
No, the last contact was more like: We're way ahead and we're trying to achieve different things
> nothing new there, then
grover> So this is more of an attempt to show them what we can provide them with.
22:42 < tgiphil> Their leadership is not very interested. But their device driver code is a mess, unsafe code everywhere.
22:42 < rootnode> grover: copton
is the one I introduced on the discussion board with the RIOT framework
grover> copton_ hi
grover> welcome to our show :)
22:42 < rootnode> copton
: one possibility could be porting your riot framework to C# ;)
22:42 < tgiphil> I was hoping to demo our drivers with their OS.
22:42 < rootnode_> another possibility would be anything else you want to help with
grover> I'm lurking in their mailing list and their activity has changed more towards trying to match what we've got recently
22:43 < rootnode_> or if you know other coders that could be interested in here
22:43 < tgiphil> ^ yeah, emitting binary directly
22:43 < rootnode>
_grover: not really....?
grover> e.g. they're working on binary emission now, covering their code with tests
grover> removing the NASM dependency entirely
> healthy competition, then.
grover> yes indeed
22:44 < rootnode>
_grover: if I get it right: first of all they "rejected" us and now they're trying to match what we've got?
> I have a feeling, though, that's what they'll remain - competition. By their own accord.
grover> I wouldn't say that
grover> rootnode: I think they see the benefits of what we did and now go back some squares to do their homework
I agree. Can't get them all.
> No sense in wasting more eBreath on them. Next? :)
grover> Anything else in drivers?
22:46 < tgiphil> Otherwise, there not too much going on with workable device drivers... just coding for eventuality. I'm working on the following device drivers in the near future: S3 Trio64 V2 and Intel 440BX. These are emulated by VirtualPC. We
already have a graphics driver for VMware (untested, of course).
22:46 < copton>
22:46 < Z98> tgiphil: question
> tgiphil: I'd request a return to attributes as soon as is practical. The explosion of interfaces I saw in the SVN logs scare me. :D
22:47 < tgiphil> I'm done with device drivers, unless anyone has any questions.
22:47 < copton> rootnode
: I see no problem in porting riot. The software architecture is generic.
22:47 < Z98> is it your intention that all these drivers be completely managed code?
22:47 < copton> rootnode
: are you sure that the requirements fit? I have little knowledge about mosa up to now
grover> copton_: We should talk about this a bit later on if you have time.
22:48 < tgiphil> TechGuy: I'll plan on bring it back. Although, as I read up on PCI bridges, we won't be able to do everything with attributes, or at least, I'm thinking about it.
22:48 < copton>
_grover: ok, no problem.
22:48 < tgiphil> Lots of legacy mode stuff even with PCI.
> multiple attributes, then? Maybe a
] attribute set, etc?
grover> tgiphil: Does it make sense to write up a couple of these harder examples to get some discussion going there?
22:50 < tgiphil> Yes, and it just depends on the hardware we will target.
> IMO, P4-class onward.
22:51 < tgiphil> I'll create a wiki pages of interesting stuff as I come across it.
grover> ok. Lets phrase it this way: We should target current hardware now, but should not prevent us from scaling.
grover> I'd like to get a design for these things going via our RFC process.
grover> As this gives rootnode_ and me some grounds to adopt our own timeline.
22:52 < tgiphil> I'd like to drawn this line, support virtual emulation software (which has some legacy stuff in it), and then PCI only on real hardware.
> already started on my desktop for the overall runtime / VM side.
22:52 < tgiphil> PCI-ISA bridges included.
22:52 * Z98 pokes tgiphil
grover> Z98: Our goal is for these drivers to be managed-code-only.
22:53 < Z98> and is the intention to treat things as objects or files?
22:54 < tgiphil> in other words, a PCI controller is required.
> Z98: Though the usage of those objects, whether continuing as objects or files, is up to the OS
> tgiphil: Ya. I'm trying to run through my list, what might be behind the ISA bridge.
grover> I have some very special thoughts on the kernel model, which I hope will be used by our clients :)
22:54 < tgiphil> IDE, Serial, Floppy, etc. it depends on the chipset.
> none of which really are still around. Or more likely emulated by USB
22:55 < Z98> serial is still around
22:55 < Z98> even if the port itself isn't present
22:55 < tgiphil> the PCI-ISA bridge implements it.
> (FYI Vista & Win2k8 provide support, but are not enabled by default. MS is on record as removing ISA support in the next release)
grover> (on the embedded boards I work with this is all real hardware.)
22:55 * Z98 wouldn't blame them
22:56 < tgiphil> I'd rather not probe for the ISA stuff and let the PCI driver, go turn it on.
grover: I miss embedded coding on the HC12. Read that article about a RTOS kernel for HC12 in this month's Dr. Dobbs. Got a soft spot in my heart.
22:56 < tgiphil> and in fact, if possible, turn off legacy mode for the PCI device. That way IO port & memory addresses can be re-located.
22:57 < tgiphil> yeah, we can talk about the offline.
grover> ok, I'd like to fix the following things:
22:57 < tgiphil> next
> I think the booting / VM topic has more or less been covered by proxy the past half hour?
grover> please wait
22:58 < Z98> not entirely
grover> 1. We will start an RFC process on the driver model, tgiphil will provide us with some examples what couldn't be covered with the attributes previously
22:59 < tgiphil> roger.
grover> 2. I'll write up a draft RFC on the kernel model to develop the idea of kernel services and how (usermode-)apps and other services/drivers will interact.
22:59 -!- Boddlnagg1
has joined #mosa
22:59 < Z98> user mode?
22:59 < Z98> we have a user mode?
grover> not a real user-mode
> That would have to be a suggestive
I'd like for you to join that discussion in order to make it that way
grover> the point being that we're talking about a lot of things without having a common coarse model on our minds.
> I'm almost borderline on just making it a wiki page and not an RFC of any form. RFC might seem too... official? (i.e. "this is the way you should use MOSA", rather than "here's an idea...")
grover> It depends because it may/will affect the way we write the kernel services we provide
23:01 < tgiphil> Wiki document is okay with me.
> I'll wait for your draft definition of kernel services. :)
grover> It is okay with me too. An RFC would have a more mandatory status IMO
Memory Management, Plug&Play, Graphics Subsystem...
grover> anyways, next topic is Booting
> Client OS realm, with ties back to the VM. But anyway...
grover> I'm not sure what the current status is there - anyone?
23:03 < Z98> umm
> it boots
23:03 < rootnode_> I think, everything before 1.0 isn't really official since we're still experimenting
23:03 < Z98> well, current status would be, i'm trying to figure out how to do the page table construction
> Anything further is the realm of the runtime / client OS again, I think
23:03 < Z98> i have a fairly good idea of how to do it
23:04 < Z98> but i need to know what information i have when the kernel is setting itself up
grover> Z98: Listening
23:04 < Z98> we need to switch over to using page tables as early as possible
23:04 < Z98> we'll likely have some drivers, the kernel, and maybe the NLS tables, assuming we do use NLS tables
grover> Right now I have this fanatic idea of not assuming any information is available. So I'd like to be able to boot, if we don't have any info.
23:05 < tgiphil> grover -> is it same to assume, we'll have a MMU on all our targets platforms?
grover> tgiphil: No.
> Embedded usually doesn't have MMU
grover> Most will have an MMU of some sort, but embedded almost never does.
23:06 < Z98> we'll cross that bridge when we get there
grover> because it hampers realtime capabilities
23:06 < Z98> i know nothing about embedded memory systems
grover> they're flat/linear.
grover> and almost always unprotected.
> Then again, most suggested MOSA-client OS designs to this point are going to use SMA
grover> anyways, Z98: the boot concept is that a bootloader will load a boot image into memory and run it.
23:07 < tgiphil> SMA?
grover> Nothing else is there at this point.
> Single-Mode Addressing
23:07 < tgiphil> gotcha
23:07 < Z98> well, i need to know the size of the kernel, or more specifically, where i can put together the page tables
grover> Multiboot gives us some info, such as amount of memory, but we should run without it
23:07 < Z98> i don't want to start overwriting stuff in memory
grover> How much space do you need?
grover> Could we reserve this with a linker script?
23:08 < Z98> not that much
grover / Z98: Can I seriously recommend limiting the scope of the MOSA "boot kernel", to join the kernel wiki page as more of a semi-reference suggestion? Again, I'll kick and scream. Boot loaders, kernels, etc are all client
OS territory, IMO.
23:08 < tgiphil> on x86, we'll need the memory map at the very minimum.
23:09 < Z98> uh
23:09 < Z98> what?
You'll have to excuse me, but this is the first time in a long time anyone from a "client" OS has been around in a meeting.
> true, sorry.
grover> I have made my own thoughts (probably wrongly) but we need some grounds to make our discussions
23:10 < Z98> the reason i bring this up is because, if we can't rely on the bootloader to set up the virtual page tables for us
23:10 < Z98> then the memory manager is going to have to do it
23:10 < tgiphil> I think the virtual pages should be setup in the kernel and not the bootloader.
grover: Solely my own fault / lack of time the past few months.
grover> It is impossible to discuss anything without getting into that territory. I'm with you on your concerns and it is important to get a common terminology and make it workable for us all, but we still need to be able to discuss.
23:11 < rootnode_> ok, next question ahead. make the kernel native or managed? :)
grover> Z98: Assume it has to do it.
23:11 < rootnode_> meaning: boot a mini-kernel just including the compiler and then run the real kernel?
No offense. Just something we need to work on.
23:11 < Z98> which is why i'm saying, by the time we get to the point where the MM is initializing, it needs to know certain pieces of information
grover> Z98: Could you provide a Wiki page with a list of these pieces?
23:12 < Z98> uh, which mosa site?
> FYI, though, in my bootloader / kernel design, and this is also how JNode works at last look, the bootloader sets up
paging. Just enough to get going. All further page table setup is delegated to the kernel itself
23:12 * Z98 has been completely distracted the past few months
grover> What I'd like to have is a page for this memory management service: Requires, Gives, Does, Uses...
23:13 < Z98> there's going to be several levels
grover> So kind of like a birds-eye view without any algorithms, but dependencies
23:13 < Z98> is the managed heap going to be considered part of the MM?
grover> we'll start with the lowest
23:13 < Z98> yay
grover> the managed heap is a thing in a process
grover> what we're talking about is physical memory management
23:13 < Z98>
: well, i would at least expect the bootloader to switch us over to protected mode
> Z98: Most likely the prior bootloader's already done that (GRUB?)
grover> Z98: Ok, assume that by the time you're initialized/started via an interface call we'll be in protected mode.
23:14 < Z98> i'll do a writeup of my "assumptions" and "requirements"
grover> with a flat linear address space
23:14 < Z98> but that was the main thing i wanted to make clear
23:15 < Z98> and that's about it at this point
grover> I'm aware that memory management is not covered in one component and that it has a multitude of layers. In order to make others aware of it, please draw a diagram that illustrates the collaborators of a full memory management
system up to the managed heap
23:15 < Z98> umm
grover> in theory
23:16 < Z98> let's see if i can think through that many layers without shooting myself in the foot
23:16 < Z98> about all i can promise is that the intention of the MM is to hand the managed heap a block of virtual addresses
> crap. Just got my call. Have to go. On the last topic, I think everyone already knows my opinion on CodePlex. :)
23:16 < Z98> after that, it's up to the managed heap
23:16 < tgiphil> ^ Z98 feel free to modify my powerpoint on the subject.
23:16 -!- Boddlnagg
Connection timed out
23:16 -!- Boddlnagg1 is now known as Boddlnagg
grover> I think this is the perfect time to get this covered
23:17 < Z98> tgiphil: is it also on the codeplex page?
23:17 < tgiphil> no, I'll e-mail it to you.
23:17 < Z98> okay
23:17 < Z98> we have newsletters?
grover> We used to with our mailing list. We'll talk about it in a couple of minutes.
grover> zMooTh: I'm sorry we skipped you earlier
23:18 < Z98> how is the wiki even organized, by the way?
grover> Z98: We don't have a wiki part for kernel services yet I believe
23:19 < zMooTh> no problem... i think we won't have to make a big discussion about it
grover> Start one
23:19 < Z98> uh
23:19 < Z98> how do i make a new page on this wiki?
grover> Z98: Start a page for your stuff, and we'll move it appropriately
23:19 * Z98 has never used codeplex before
23:20 < tgiphil> z98 -> we can talk later/offline about this.
23:20 < Z98> okay
23:20 * Z98 away for food, is starving
23:20 < tgiphil> I'm not happy with CodePlex support for SVN. It's support for "svn update" is buggy - seems to break when moving/renaming files or directories.
grover> Anyways for everyone else not involved in the compiler work: zMooTh has been working on some theory in order to allow mosacl and other compilers based on the MOSA compiler framework to use linker scripts
grover> He prepared a concept to integrate these linker scripts into mosacl in order to move executable sections to specific addresses
grover> anything I should add zMooTh?
23:22 < zMooTh> mmmh no
23:22 < zMooTh> it's ok
23:22 < tgiphil> zMooth -> very cool.
grover> Do you want to introduce some of your work or is it to much detail?
23:23 < zMooTh> actually i'm at the start... so theres just the theory
23:23 < zMooTh> i think we should talk about the details, when there is some code to talk about it
23:24 < zMooTh> but i got a few questions left
23:24 < zMooTh> talk about it now?
grover> We can clear it up later
23:24 < zMooTh> ok
grover> Next up is the CodePlex experience
grover> Actually I'm not only thinking about codeplex here, but the entire experience we have right now if someone new wants to join us
grover> First codeplex though
grover> I'm not really happy using it to be honest
23:25 < Boddlnagg> you're not the only one
23:26 < rootnode_> hm, since I used vs team explorer I had no problems
grover> My "difficulties" are the TFS dependency, because working with SVN is almost impossible.
23:26 < rootnode_> but at least the server is stable
grover> The other thing I really miss is the mailing list we had.
23:27 < tgiphil> The Visual Studio Explorer Client works perfectly.
grover> Yes, but not everyone works with Visual Studio.
23:27 < tgiphil> (not to disagree too much) I'm happy with the way the discussions/mailing list works.
23:27 < Boddlnagg> yep
23:27 < Boddlnagg> (at
grover> discussions imho does not replace a mailing list
grover> it is more like a forum
23:28 < tgiphil> I think they'll fix the SVN problems eventually... they did fix the SVN bug that I reported in only a few hours.
grover> the point is: You can only subscribe to discussions if you join a project
grover> At least I wasn't able to. With mailing lists this is much easier.
grover> I don't want to argue against codeplex, just want to express my unhappiness
23:29 < tgiphil> ^ you can only subscribe if you enroll with the site... (not necessarily join the project as a developer).
grover> tgiphil: what was the reason we stopped using your server?
23:29 < tgiphil> redmine crashed all the time.
grover> So this was a redmine issue
23:29 < rootnode_> and svn crashed
23:29 < tgiphil> the SVN worked perfectly.
grover> yes and I really miss it when I'm on my mac
grover> I'm looking around personally for a virtual server
grover> and I was thinking about setting one up for MOSA again
23:31 < rootnode_> me too
grover> the offer I've looked at in more detail is at 8Ä/month
23:31 < rootnode_> I quit the contract with my old provider and am looking for a new one
23:32 < tgiphil> but running what? redmine doesn't seem stable on either linux or windows.
23:32 < rootnode_> traxx?
23:32 < rootnode_> trac?
23:32 < tgiphil> trac, it's just like redmine.
grover> JIRA seems to be really pro
grover> and I'm trying to get their stuff at work
grover> I still think we need cruise control, an issue management, a wiki, svn all integrated
23:34 < tgiphil> ^ I agree
grover> it seems that JIRA is able to offer us this
23:34 < rootnode_> ah, wait a sec
23:34 < rootnode_> someone told me about a new one lately
23:34 < tgiphil> JIRA -> do they offer free licenses for open source projects... seems to be hit and miss.
grover> Btw. this is the offer I was talking about: https://www.server4you.de/de/vserver/showplan.php?products=0
grover> JIRA does offer free licenses for open source, it depends on certain things to get it. But we may be lucky
grover> Regarding SVN: I've had contact with Pablo from PlasticSCM, which seems to be really nice in handling and displaying large branches which we'll definitely have in the future
grover> He was offering us a free license for it
grover> fully .NET, running on Mono
23:36 < rootnode>
_grover: I've been looking around for a server too, as soon as my old server is deleted
23:36 < tgiphil> Yeah, it looks interesting.
23:37 < rootnode_> with a vServer we could also create a real website
grover> What are the thoughts of others? Should we stay with codeplex or try to move away again?
23:37 < Boddlnagg> move away.
23:38 < Boddlnagg> rootnode_: hm, a real website would be nice, too
23:38 < Boddlnagg> if someone creates it
23:38 < tgiphil> I say stay. Mostly until we have a better solution available. JIRA or whatever it might be.
23:38 < rootnode_> I'd offer to create the server
23:39 < tgiphil> it's not the hardware - it's what we decide to run on it.
23:39 < Boddlnagg> we could use mod_mono and code it in asp.net/c#^^
grover> tgiphil: I agree
grover> rootnode_: I was actually thinking of creating a donation system to run the servers
23:40 < rootnode_> no problem :D
23:40 < tgiphil> I was willing to dedicate hardware to mosa (with 99% uptime). But not if the software crashes all the time.
23:41 < rootnode_> if people donate, just give the money for the server costs, and the rest can go to someones account. I don't care
23:42 < tgiphil> unfortunately, there not a lot of good software solutions.
grover> tgiphil: I understand that and I'm very thankful you did
23:42 < zMooTh> hmmm how much traffic an webspace would be needed?
grover> However I think the fires in your area has shown that we should move to a datacenter with more protection.
23:42 < Z98> hmm
grover> Codeplex was the right decision for that
23:43 < Z98> let me ask the ROS devs
23:43 < Z98> see if they're willing to share space
grover> Z98: The point is not the space, the point is the tools.
23:43 < tgiphil> Do we need SVN integration with the web site?
grover> I think it would be a plus
23:43 < tgiphil> if not, maybe a simple wiki would be better.
23:44 < Z98>
grover: and what specific tools are you referring to?
grover> well redmine has failed us twice now
grover> so Codeplex was a move to make the repository and tools available with more than 99% uptime
23:44 < Z98> i assume you want a content management system and a repository?
23:44 < Z98> cause we've got both
23:45 < Z98> we use SVN in ROS
grover> a CMS and SVN are of course required, a bug tracking tool and integrated continuous integration would be really nice
23:45 < Z98> integrated continuous integration?
23:46 < Z98> we have bugzilla, too
grover> Z98: Something like cruise control .net
grover> really required as we all tend to break builds :)
grover> mostly me :p
23:48 < Z98> oh, this
23:48 < Z98> we actually discussed this in the ROS project
23:48 < Z98> there was debate as to whether we should move to mercurial or git to make branching and merging easier
23:49 < Z98> the current consensus is, be careful, as longer term solutions will take much longer to work out
grover> I don't think the merging/branching really makes this easier
23:49 < Z98> well, the other thing is, we don't do that much dev work in branches to begin with
grover> especially if there's more than one person working on a "feature"
23:50 < tgiphil> btw. In the mean time, I'm going to work with the SVNBridge developer to fix the SVN bugs.
grover> MOSA right now not at all
grover> tgiphil: good
23:51 < Z98> what exactly is the problem?
23:51 < Z98> that you guys are running into that you want something like that?
grover> IMHO codeplex isn't as accessible as it could be for other devs.
grover> (new ones)
grover> SourceForge is terrible
grover> tgiphil had issues with redmine
23:52 < tgiphil> sharpos had issues with redmine also.
grover> so I'm just trying to explore the alternatives
23:53 < rootnode_> sourceforge is not an option at all
grover> ensemble doesn't but it could either be luck or lack of load
23:53 < tgiphil> ^ agreed about sourceforge.
grover> ^ me too
23:54 < tgiphil> TechGuy -> didn't you have problems with redmine?
grover> Anyways, I'll try to acquire a JIRA license for us - if we get it, okay
grover> if not we'll have to look further
23:54 < rootnode_> ok
23:54 < rootnode_> and what about the server?
23:54 < tgiphil> do we need a server? or will they host it?
grover> I think they will only give us a license to use it. No hosting.
23:55 < Z98> hmm
23:55 < Z98> JIRA?
23:55 < Z98> anyways, you can poke around the ROS site and see how "accessible" you think it is
23:55 < rootnode_> I'd provide the vserver
23:55 < rootnode_> just tell me
grover> rootnode_: I agree with tgiphil in that any alternative should not be rushed
23:56 < rootnode_> i know
23:56 < tgiphil> if we need a server, we should place it somewhere stable.
grover> if we get the software, have a complete setup and everything else is 90% ready too we could think about a move
grover> tgiphil: Agreed.
grover> Anyways, do you think a donation system would work? Paypal or something like it with 2-3Ä/per person/month?
23:59 < rootnode_> donations would work, yes
23:59 < tgiphil> I see it work were a few people donate, lets say, $20 up front.
23:59 < rootnode_> oh, zmooth just had an idea
23:59 < rootnode_> perhaps we could move to an university server
23:59 < rootnode_> this would provide us with endless traffic and a 100gbit connection
--- Day changed Sun Dec 28 2008
00:00 < Z98> assuming we can keep that server
00:00 < Z98> indefinitely
grover> the problem I see with those servers is backup & maintenance
00:00 < rootnode_> maintenance is no problem at all
grover> I don't want one of us tied up with these tasks
00:01 < rootnode_> software problems can be solved by everyone on the team
00:01 < rootnode_> if it has to do with hardware either the people at university or I could do it
00:01 < rootnode_> I need 5 minutes to be there if I walk
grover> But you're not there in 5 years (I hope :))
00:02 < rootnode_> I hope so and not :D
00:02 < rootnode_> working there after graduation would be nice too ;)
00:02 < rootnode_> ok, working in japan would be more nice
00:03 < Z98> we have our own server in a datacenter :P
00:03 < tgiphil> fyi: reported problem with SVN Bridge: http://www.codeplex.com/SvnBridge/Thread/View.aspx?ThreadId=43069
00:03 < zMooTh> rootnode_: nah... you'll be the next programming professor
00:03 < zMooTh> ;)
00:03 < rootnode_> working with prof. giesl, yeah
00:03 < rootnode_> ok, back to topic
00:03 < zMooTh> ^^
00:03 < Z98> anyways, i'm away
00:04 < Z98> whatever you guys do figure out, that SVN problem does need to be fixed, or else i'm gonna have issues updating
grover> Ok I think we can finish this
00:04 < Z98> which kinda kills motivation to work :P
00:04 < zMooTh> let us think about a server, when there is a system to change to
grover> Anything else someone wants to add?
00:04 < tgiphil> ^ agreed.
00:04 < Boddlnagg> Z98: same for me
00:04 < tgiphil> yeh, the boot image process. Everyone okay with it? suggestions?
grover> yes: Everyone: Please use the map file switch
grover> Right now its not that hard to locate code in the created binary image, but it will be harder each day
00:06 < tgiphil> grover -> is there a wiki page on the compile optons for mosacl? And samples?
grover> I did work on it when codeplex crashed on me
grover> site was unusable in the browser after submitting it and the page wasn't submitted
grover> and since it's all ajax powered it lost my content
00:07 < tgiphil> :( Copy before hitting submit. It happens occassionally.
grover> Didn't want to rewrite half an hour of work...
00:07 < Boddlnagg> so another argument against codeplex
grover> Boddlnagg: May happen with everything.
grover> Happened to me on redmine, but I knew about it there
grover> On codeplex I just wasn't prepared
00:08 < tgiphil> It happens with gmail all the time.
00:08 < Boddlnagg> never happened to me anywhere :-/
grover> anyways there's the help switch, which tells all known switches
grover> since its built by the parser
00:09 < tgiphil> here's the page for the MakeBootImage tool: http://www.codeplex.com/mosa/Wiki/View.aspx?title=Make%20Boot%20Image%20Tool&referringTitle=MOSA%20Tools.
grover> Anyways, unless there's something else I'd call this meeting finished
00:12 < tgiphil> agreed.
grover> LogNode: Please upload the log into the wiki and link it
00:15 < Boddlnagg> what's up with copton now?
grover> hm copton, rootnode
00:15 < rootnode_> pong
00:15 < rootnode_> ok
00:15 < rootnode_> wait
00:16 < rootnode_> now?
00:16 < rootnode_> so we're finished?
00:16 < rootnode_> have to cut it, wait a sec