On Mar 10, 2007, at 10:39 PM, Andreas Raab wrote:

> Brian Rice wrote:
>> On Mar 10, 2007, at 5:51 PM, Andreas Raab wrote:
>>> Which, if you start a new platform branch instead of trying to  
>>> patch existing ones, shouldn't be a problem I think.
>> This sounds promising, but most of us with interest in handhelds  
>> aren't experienced (Squeak) VM hackers, and are not aware of the  
>> process involved, especially if we are making relatively slight  
>> tweaks to a mature branch, like the Unix branch for the Zaurus PDA  
>> or Nokia internet tablets. In a lot of these cases, it's a  
>> configuration issue, and the way to make a platform branch that is  
>> maintainable is not clear.
>
> I agree. But a large part of making such tweaks in a separate  
> platform branch is to spend a bit of time to learn the (admittedly  
> imperfect) build structure. I think we all agree that it's  
> imperfect but it's the best we could come up with so far, so  
> willingness to learn it and live inside it is a must if you want to  
> take on this task seriously.
>
>> Most of the existing ports are currently just tarballs of some  
>> modified snapshot of the VM sources from a while ago, so it seems  
>> like people have found it easiest so far to just hack until it  
>> worked and then archive for posterity.
>
> That may well be. How would you propose to change that? As far as I  
> can remember over the history of Squeak, this is how all ports  
> started. The main difference between those at SqueakVM.org and  
> those not is that some of them were supported over a period of  
> time, and some of them weren't. If you make a one-shot solution,  
> there is not much value in bringing into the common build structure  
> at SqueakVM.org. If you spend a longer time it starts to make a lot  
> more sense.

Mostly through a couple of web pages that guide the newbie VM hacker  
in the right direction. The initial steps are easy, just throwing up  
a web page that explains the state of things (culled from these or  
similar messages) and how to ask to do stuff that is not supported  
yet, and the second part, how to learn from the build structure to  
make a new port, would involve one person actually going through the  
process and being able to channel that feedback into those online pages.

>> As a non-handheld, but practical example, there have been (mostly- 
>> working, but now no longer on the 'net) BeOS ports of some  
>> versions of the VM, but it's never gotten to the point where those  
>> ports met the main repositories. That's an example of a port whose  
>> solution might tell the solver what documentation needs to be  
>> available to complete other such ports. Making one solution  
>> tractable would make the solution of the handheld problems nearly  
>> as tractable.
>
> I'm trying to be serious here but do you really expect the port  
> maintainers to go hunting for unsupported ports, and fold them into  
> the common build structure? I think that's a bit of an expectation  
> mismatch. The people who maintain "their" ports do it *precisely*  
> because they like their platform. If you like BeOS, and want to add  
> it to the common build structure and maintain it, please go for it!  
> But asking other people to maintain ports in which they basically  
> have no interest seems a bit far fetched.

Oh, not at all. Actually the idea is to get one person to try this  
approach with their pet port project, particularly where the person  
isn't part of the core team and doesn't have implicit knowledge about  
all this. The BeOS port authors still have websites and can be  
contacted for their stuff and maybe even asked about their  
experiences with it.

>> Another thing occurs to me: one of the factors that makes  
>> coordinating Squeak VM development for PDAs is that there are many  
>> toolchains (even if gcc-based) for these different systems, and  
>> some are proprietary (MSVC), so no one person will likely be able  
>> to understand or vet all the ports (especially Ian or you, who  
>> have many things on your plates).
>
> But this is exactly why we have platform branches to begin with.  
> WinCE for example - a long time ago we had a separate port for  
> WinCE, which I folded into the main Win32 port around 1998 or so.  
> Later it turned out to be unfeasible simply because CE was missing  
> so many features that you take for granted on Win32 in general and  
> these ports again split. Today, the "main" win32 port is built with  
> a setup that is specifically available on SqueakVM.org (only FOSS  
> build tools btw, so *everyone* can build that VM) and the last  
> versions of WinCE were being built with an MS proprietary toolset.  
> Fine with me, and worth a separate platform branch as far as I am  
> concerned. OTOH, I just asked Eliot if he could make the VC++  
> makefiles for the main Win32 port available since he's just been  
> working on this. Both are fine ways to deal with it and I am open  
> to either one.

Oh, okay. Cool.

>> So, here are the questions that occur to me:
>> - Is there a guide for how to do this?
>
> To do what exactly? Make a "minor port" that leverages a "major"  
> port and just tweaks it slightly? I would guess that depends on how  
> much magic you do with your build setup. For example, the current  
> win32 build looks for files first in the win32 tree, then in the  
> cross tree. For a "minor" port to leverage this it would be quite  
> doable to have a build setup that first looks in, say "WinCE", then  
> "Win32", then "Cross" etc. It is some work, sure, and it may  
> require some communication with the "main" port but it's definitely  
> doable.

Okay.

>> - If you do find it easy enough to explain in an email, how can we  
>> put it on an official Squeak site where it is likely to be found?  
>> (The wiki is great, or a README in the SVN tree, but there should  
>> at least be a link from squeakvm.org's page or something.)
>
> I don't quite understand what you mean here. PR is not my main  
> task ;-)

Yeah, it wasn't personally directed at you.

>> - What is the recommended process for submitting patches for such  
>> a branch when the level of interaction isn't high enough to merit  
>> asking for write access to the SVN server?
>
> Maintaining a platform port *is* worth asking for write access. And  
> like I said before, I wouldn't expect that to be any problem  
> whatsoever. If you have patches for a port, post them to vm-dev.

Okay.

>> - If a permanent account to the SVN server is justified, how does  
>> one make that request?
>
> Starting with the work you've already done (e.g., at least some  
> partial work result to show you are serious about it) sending a  
> nice request to Ian (he owns the physical box) with CC: to vm-dev  
> would be all that is needed. If nothing happens in a couple of  
> weeks (sometimes people are just busy) follow up on vm-dev.

Okay.

>> This kind of information should be published in an obvious place  
>> rather than repeated on email.
>
> Like I was saying before, I don't own the PR on VM stuff. Knock  
> yourself out if you like, in fact we could probably use someone who  
> owns these aspects of vm-dev ;-) If you are willing to write a bit  
> of documentation about it, I think that would be quite welcome.

Thanks. I'll contact Ian (he owns squeakvm.org) and see about a short- 
term project to make/coordinate the described progress. (Not that I'm  
going to give up, but limited-scope is what makes these ideas work.)

--
-Brian
http://briantrice.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070311/d03dc938/PGP.pgp