Checking contributors to VM code base

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Checking contributors to VM code base

timrowledge
 
I'm going to make a pass at establishing the identities of all the  
contributors to the VM codebase so we can (hopefully) declare it MIT  
clean on squeaksource etc.

If anyone has code that can help to extract method stamp initials from  
all the VMMaker package code I'd be very happy to receive a copy; I  
don't want to duplicate effort. There's several dozen mcz packages to  
scan and there are many, many changeset files from before the  
existence of VMMaker as well. I think it unlikely that there is anyone  
not already signed up for the relicensing but better safe than sued.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- A room temperature IQ.


Reply | Threaded
Open this post in threaded view
|

Re: Checking contributors to VM code base

johnmci
 
Obviously don't forget the C source code (non slang generated) in this  
review.


On Apr 2, 2008, at 1:36 PM, tim Rowledge wrote:

> I'm going to make a pass at establishing the identities of all the  
> contributors to the VM codebase so we can (hopefully) declare it MIT  
> clean on squeaksource etc.
>
> If anyone has code that can help to extract method stamp initials  
> from all the VMMaker package code I'd be very happy to receive a  
> copy; I don't want to duplicate effort. There's several dozen mcz  
> packages to scan and there are many, many changeset files from  
> before the existence of VMMaker as well. I think it unlikely that  
> there is anyone not already signed up for the relicensing but better  
> safe than sued.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- A room temperature IQ.
>
>

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================


Reply | Threaded
Open this post in threaded view
|

Re: Checking contributors to VM code base

timrowledge
In reply to this post by timrowledge
 
So no responses at all to this? Does anyone care about the license  
status of VMMaker?

On 2-Apr-08, at 1:36 PM, tim Rowledge wrote:

> I'm going to make a pass at establishing the identities of all the  
> contributors to the VM codebase so we can (hopefully) declare it MIT  
> clean on squeaksource etc.
>
> If anyone has code that can help to extract method stamp initials  
> from all the VMMaker package code I'd be very happy to receive a  
> copy; I don't want to duplicate effort. There's several dozen mcz  
> packages to scan and there are many, many changeset files from  
> before the existence of VMMaker as well. I think it unlikely that  
> there is anyone not already signed up for the relicensing but better  
> safe than sued.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- A room temperature IQ.
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Klingon Code Warrior:- 1) "Behold, the keyboard of Kalis!  The  
greatest Klingon code warrior that ever lived!"


Reply | Threaded
Open this post in threaded view
|

Re: Checking contributors to VM code base

Ken G. Brown
In reply to this post by timrowledge
 
Don't have what you need. However since you appear to be working on VMMaker, I was wondering about your take on the need for having plugins in the VMMaker Plugins category. At least it seemed to me that you have to put them there in order for VMMaker to pick them up.
Somehow it seems odd to me to have all of a plugin's classes in its own category, except the plugin which has to go somewhat illogically in the VMMaker Plugin category. Most likely its a lot of work to do it any other way. Or am I missing something?

Ken G. Brown
 

At 7:45 PM -0700 4/10/08, tim Rowledge apparently wrote:

>So no responses at all to this? Does anyone care about the license status of VMMaker?
>
>On 2-Apr-08, at 1:36 PM, tim Rowledge wrote:
>
>>I'm going to make a pass at establishing the identities of all the contributors to the VM codebase so we can (hopefully) declare it MIT clean on squeaksource etc.
>>
>>If anyone has code that can help to extract method stamp initials from all the VMMaker package code I'd be very happy to receive a copy; I don't want to duplicate effort. There's several dozen mcz packages to scan and there are many, many changeset files from before the existence of VMMaker as well. I think it unlikely that there is anyone not already signed up for the relicensing but better safe than sued.
>>
>>tim
>>--
>>tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>Useful random insult:- A room temperature IQ.
>>
>
>
>tim
>--
>tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>Klingon Code Warrior:- 1) "Behold, the keyboard of Kalis!  The greatest Klingon code warrior that ever lived!"

Reply | Threaded
Open this post in threaded view
|

Re: Re: Checking contributors to VM code base

Andreas.Raab
In reply to this post by timrowledge
 
Not sure what you're looking for. All I have is already up at
http://ftp.squeak.org/history - if there's anything in particular I can
help with, let me know.

Cheers,
   - Andreas

tim Rowledge wrote:

>
> So no responses at all to this? Does anyone care about the license
> status of VMMaker?
>
> On 2-Apr-08, at 1:36 PM, tim Rowledge wrote:
>
>> I'm going to make a pass at establishing the identities of all the
>> contributors to the VM codebase so we can (hopefully) declare it MIT
>> clean on squeaksource etc.
>>
>> If anyone has code that can help to extract method stamp initials from
>> all the VMMaker package code I'd be very happy to receive a copy; I
>> don't want to duplicate effort. There's several dozen mcz packages to
>> scan and there are many, many changeset files from before the
>> existence of VMMaker as well. I think it unlikely that there is anyone
>> not already signed up for the relicensing but better safe than sued.
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Useful random insult:- A room temperature IQ.
>>
>>
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Klingon Code Warrior:- 1) "Behold, the keyboard of Kalis!  The greatest
> Klingon code warrior that ever lived!"
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: Checking contributors to VM code base

timrowledge
In reply to this post by Ken G. Brown
 

On 10-Apr-08, at 8:21 PM, Ken G. Brown wrote:

>
> Don't have what you need. However since you appear to be working on  
> VMMaker, I was wondering about your take on the need for having  
> plugins in the VMMaker Plugins category. At least it seemed to me  
> that you have to put them there in order for VMMaker to pick them up.
> Somehow it seems odd to me to have all of a plugin's classes in its  
> own category, except the plugin which has to go somewhat illogically  
> in the VMMaker Plugin category. Most likely its a lot of work to do  
> it any other way. Or am I missing something?
Well the main list of plugin classes to work on is derived from
providedPlugins
        "generate the list by asking the InterpreterPlugins"
        ^ ((InterpreterPlugin allSubclasses
                select: [:cl | cl shouldBeTranslated])
                collect: [:cl | cl name]) asSortedCollection
so, yes, I think you've got confused.

 From there any plugin has to be moved to either the internal or  
external list in order to get actually processed - the UI in  
VMMakerTool does it by direct manipulation and the various methods in  
VMMaker>initialize like initializeInternal:external: allow for  
scripted usage.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IA: Illogical And


Reply | Threaded
Open this post in threaded view
|

Re: Re: Checking contributors to VM code base

Ken G. Brown
In reply to this post by Ken G. Brown
 
At 10:27 PM -0700 4/10/08, tim Rowledge apparently wrote:

>On 10-Apr-08, at 8:21 PM, Ken G. Brown wrote:
>
>>
>>Don't have what you need. However since you appear to be working on VMMaker, I was wondering about your take on the need for having plugins in the VMMaker Plugins category. At least it seemed to me that you have to put them there in order for VMMaker to pick them up.
>>Somehow it seems odd to me to have all of a plugin's classes in its own category, except the plugin which has to go somewhat illogically in the VMMaker Plugin category. Most likely its a lot of work to do it any other way. Or am I missing something?
>Well the main list of plugin classes to work on is derived from
>providedPlugins
> "generate the list by asking the InterpreterPlugins"
> ^ ((InterpreterPlugin allSubclasses
> select: [:cl | cl shouldBeTranslated])
> collect: [:cl | cl name]) asSortedCollection
>so, yes, I think you've got confused.

Hmmm...ok. The way it works is making more sense to me then. I had added plugin code to the image but for some reason, I did not see it in VMMakerTool 'Plugins Not Built' list until I changed the plugin category to VMMaker-Plugins, I had assumed that was where it needed to live in order to be picked up in the list. I'll try moving the plugin back to its own category and see if I can duplicate what I thought happened.

Thx,
Ken G. Brown

>From there any plugin has to be moved to either the internal or external list in order to get actually processed - the UI in VMMakerTool does it by direct manipulation and the various methods in VMMaker>initialize like initializeInternal:external: allow for scripted usage.
>
>
>tim
>--
>tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>Strange OpCodes: IA: Illogical And

Reply | Threaded
Open this post in threaded view
|

Re: Re: Plugin category

Ken G. Brown
 
At 11:55 PM -0600 4/10/08, Ken G. Brown apparently wrote:

>
>At 10:27 PM -0700 4/10/08, tim Rowledge apparently wrote:
>>On 10-Apr-08, at 8:21 PM, Ken G. Brown wrote:
>>
>>>
>>>Don't have what you need. However since you appear to be working on VMMaker, I was wondering about your take on the need for having plugins in the VMMaker Plugins category. At least it seemed to me that you have to put them there in order for VMMaker to pick them up.
>>>Somehow it seems odd to me to have all of a plugin's classes in its own category, except the plugin which has to go somewhat illogically in the VMMaker Plugin category. Most likely its a lot of work to do it any other way. Or am I missing something?
>>Well the main list of plugin classes to work on is derived from
>>providedPlugins
>> "generate the list by asking the InterpreterPlugins"
>> ^ ((InterpreterPlugin allSubclasses
>> select: [:cl | cl shouldBeTranslated])
>> collect: [:cl | cl name]) asSortedCollection
>>so, yes, I think you've got confused.
>
>Hmmm...ok. The way it works is making more sense to me then. I had added plugin code to the image but for some reason, I did not see it in VMMakerTool 'Plugins Not Built' list until I changed the plugin category to VMMaker-Plugins, I had assumed that was where it needed to live in order to be picked up in the list. I'll try moving the plugin back to its own category and see if I can duplicate what I thought happened.

Ok, it appears what happened was that I must have had VMMakerTool open before I loaded the plugin code and it did not update or find the plugin by the time when I originally looked. I then saw the other plugins in VMMaker-Plugins so changed category of the plugin I loaded to the VMMaker-Plugins and then saw it show in the list. I don't remember for sure what I did originally, but this time, closing and opening VMMakerTool again shows the plugin properly even tho it still lives in its own category now. Great!

What are the conditions that cause VMMakerTool rebuild its lists?

Thx,
Ken

>Thx,
>Ken G. Brown
>
>>From there any plugin has to be moved to either the internal or external list in order to get actually processed - the UI in VMMakerTool does it by direct manipulation and the various methods in VMMaker>initialize like initializeInternal:external: allow for scripted usage.
>>
>>
>>tim
>>--
>>tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>Strange OpCodes: IA: Illogical And

Reply | Threaded
Open this post in threaded view
|

Re: Re: Plugin category

timrowledge
 

On 11-Apr-08, at 10:55 AM, Ken G. Brown wrote:

>
> Ok, it appears what happened was that I must have had VMMakerTool  
> open before I loaded the plugin code and it did not update or find  
> the plugin by the time when I originally looked. I then saw the  
> other plugins in VMMaker-Plugins so changed category of the plugin I  
> loaded to the VMMaker-Plugins and then saw it show in the list. I  
> don't remember for sure what I did originally, but this time,  
> closing and opening VMMakerTool again shows the plugin properly even  
> tho it still lives in its own category now. Great!
>
> What are the conditions that cause VMMakerTool rebuild its lists?

Hmm, well one would have to exhaustivley trace all the possible ways  
of #availableModules getting sent, which after a couple of quick looks  
seems to be a large number. I reckon the easiest one to use in the  
short term is the menu option 'make all available' in the middlebutton  
menus for the Plugins not built/Internal Plugins/External Plugins lists.

I expect someone could make compiling any suitable class send  
#changed: #reinitialize to any and all open VMMaker instances if it  
seems important enough.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- The wheel's spinning but the hamster's dead.