Next Etoys release

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Next Etoys release

Bert Freudenberg
(moving to etoys-dev)

Awesome! :)

- Bert -

On 22.01.2014, at 20:49, karl ramberg <[hidden email]> wrote:




On Wed, Jan 22, 2014 at 12:44 PM, Bert Freudenberg <[hidden email]> wrote:
Karl: do you want to take a stab at doing an Etoys release? I don't have the time to actually do it, but I am willing to do some hand-holding :)

I will try. Must read up on this stuff, because it is easy to mess up.

I think I will start by collecting the changes since last release.

Hand holding and maybe some help with passwords is needed.
I have changed computers a few times and I'm not sure I the subversion password.

Cheers,
Karl

- Bert -

On 21.01.2014, at 21:52, karl ramberg <[hidden email]> wrote:

We have release process but it's a little complicated.

Karl


On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte <[hidden email]> wrote:
Bert,

I saw the commit to fix the sugar interaction was done.

To generate the deb package of Etoys with the last changes, without wait for the upsream release: It is right the following procedure ?:

1) Run Etoys, and from unnamed project, update from server code.
2) Save the changes
3) Copy etoys.image and etoys.changes to my source code tree
4) Generate the deb package.


My doubt, is meanly if only etoys.image and etoys.changes are needed to copy ?


Thanks.
Gustavo.




On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte <[hidden email]> wrote:
Bert, thank a ton for the fix.

I added the bug to the tracker and upload the fix.


I gonna wait, to be included on upstream.

I hope procedure followed was be right.

Thanks.
Gustavo


On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:
Hi Gustavo,

the problem is not in the XMLDomParser, but how it it used. Apparently the way gconf stores its values changed. Previously both numeric and string values had a separate entity inside, like you discovered. Now it appears int values are stored in a more compact way.

The problem is in the SugarLauncher>>gconfPropertiesAt: method. It treats strings and int properties the same way. 

Instead of "entry elements first contentString" it might use "entry attributeAt: 'value' ifAbsent: [entry elements first contentString]". This should work with both the old and the new format. Here's the full method, patched (but untested):

gconfPropertiesAt: aString
| dir |
"search up tree to guess home dir"
dir := Project squeakletDirectory.
[dir pathName = '/'] whileFalse: [
dir := dir containingDirectory.
[FileStream
readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
do: [:f |
| props |
props := Dictionary new.
(XMLDOMParser parseDocumentFrom: f)
tagsNamed: #entry do: [:entry |
props at: (entry attributeAt: 'name')
put: (entry attributeAt: 'value'
ifAbsent: [entry elements first contentString])].
^props].
] on: FileDoesNotExistException do: [:ignore | ].
].
^self error: 'cannot find gconf path ', aString

This document describes how to publish a fix for Etoys:


If you just want to fix it in the distro rather than waiting for an upstream release, you should be able to change the method, enter the hidden unnamed top-level project, and save the image from that project (it is important to be in that project when saving the image).

- Bert -

On 16.01.2014, at 15:54, Gustavo Duarte <[hidden email]> wrote:

Hi Georg,

The xml file content is:

<?xml version="1.0"?>
<gconf>
        <entry name="color" mtime="1389708067" type="string">
                <stringvalue>#9A5200,#FF2B34</stringvalue>
        </entry>

        <entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>

        <entry name="ip" mtime="1389708044" type="string">
                <stringvalue>1.2.3.4</stringvalue>
        </entry>

        <entry name="SugarBuddyOwner" mtime="1389708044" type="string">
                <stringvalue>1234</stringvalue>
        </entry>

        <entry name="nick" mtime="1389708044" type="string">
                <stringvalue>estudiante</stringvalue>
        </entry>
</gconf>

I don't know much about xml format, but seemingly it hasn't XML schema specification, right ? 


On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann <[hidden email]> wrote:

Am 16.01.2014 um 13:10 schrieb Gustavo Duarte <[hidden email]>:

I guess that XMLDOMParser doesn't support the xml line format: 
<entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>.

I don't know much about xml format, but i think that is valid format entry, so XMLDOMParser has bug.

Whether the bug is in the parser or the file depends on the XML schema specified in the file.

Kind regards
Georg




- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Edward Cherlin
Some of us, including me, will need to see the changes in the next
release so that we can apply them to the Etoys Reference Manual.
Others who want to take a look should speak up.

When can we download and test this version?

I have just wrapped up another manual, and can come back to this one now.

On Wed, January 22, 2014 3:39 pm, Bert Freudenberg wrote:

> (moving to etoys-dev)
>
> Awesome! :)
>
> - Bert -
>
> On 22.01.2014, at 20:49, karl ramberg <[hidden email]> wrote:
>
>>
>>
>>
>> On Wed, Jan 22, 2014 at 12:44 PM, Bert Freudenberg
>> <[hidden email]> wrote:
>> Karl: do you want to take a stab at doing an Etoys release? I don't have
>> the time to actually do it, but I am willing to do some hand-holding :)
>>
>> I will try. Must read up on this stuff, because it is easy to mess up.
>>
>> I think I will start by collecting the changes since last release.
>>
>> Hand holding and maybe some help with passwords is needed.
>> I have changed computers a few times and I'm not sure I the subversion
>> password.
>>
>> Cheers,
>> Karl
>>
>> - Bert -
>>
>> On 21.01.2014, at 21:52, karl ramberg <[hidden email]> wrote:
>>
>>> We have release process but it's a little complicated.
>>> http://etoys.squeak.org/svn/trunk/Documentation/Release-HowTo.txt
>>>
>>> Karl
>>>
>>>
>>> On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte
>>> <[hidden email]> wrote:
>>> Bert,
>>>
>>> I saw the commit to fix the sugar interaction was done.
>>>
>>> To generate the deb package of Etoys with the last changes, without
>>> wait for the upsream release: It is right the following procedure ?:
>>>
>>> 1) Run Etoys, and from unnamed project, update from server code.
>>> 2) Save the changes
>>> 3) Copy etoys.image and etoys.changes to my source code tree
>>> 4) Generate the deb package.
>>>
>>>
>>> My doubt, is meanly if only etoys.image and etoys.changes are needed to
>>> copy ?
>>>
>>>
>>> Thanks.
>>> Gustavo.
>>>
>>>
>>>
>>>
>>> On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte
>>> <[hidden email]> wrote:
>>> Bert, thank a ton for the fix.
>>>
>>> I added the bug to the tracker and upload the fix.
>>>
>>> http://tracker.squeakland.org/browse/SQ-1200
>>>
>>> I gonna wait, to be included on upstream.
>>>
>>> I hope procedure followed was be right.
>>>
>>> Thanks.
>>> Gustavo
>>>
>>>
>>> On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg
>>> <[hidden email]> wrote:
>>> Hi Gustavo,
>>>
>>> the problem is not in the XMLDomParser, but how it it used. Apparently
>>> the way gconf stores its values changed. Previously both numeric and
>>> string values had a separate entity inside, like you discovered. Now it
>>> appears int values are stored in a more compact way.
>>>
>>> The problem is in the SugarLauncher>>gconfPropertiesAt: method. It
>>> treats strings and int properties the same way.
>>>
>>> Instead of "entry elements first contentString" it might use "entry
>>> attributeAt: 'value' ifAbsent: [entry elements first contentString]".
>>> This should work with both the old and the new format. Here's the full
>>> method, patched (but untested):
>>>
>>> gconfPropertiesAt: aString
>>>     | dir |
>>>     "search up tree to guess home dir"
>>>     dir := Project squeakletDirectory.
>>>     [dir pathName = '/'] whileFalse: [
>>>         dir := dir containingDirectory.
>>>         [FileStream
>>>             readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
>>>             do: [:f |
>>>                 | props |
>>>                 props := Dictionary new.
>>>                 (XMLDOMParser parseDocumentFrom: f)
>>>                     tagsNamed: #entry do: [:entry |
>>>                         props at: (entry attributeAt: 'name')
>>>                             put: (entry attributeAt: 'value'
>>>                                 ifAbsent: [entry elements first contentString])].
>>>                 ^props].
>>>         ] on: FileDoesNotExistException do: [:ignore | ].
>>>     ].
>>>     ^self error: 'cannot find gconf path ', aString
>>>
>>> This document describes how to publish a fix for Etoys:
>>>
>>> http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt
>>>
>>> If you just want to fix it in the distro rather than waiting for an
>>> upstream release, you should be able to change the method, enter the
>>> hidden unnamed top-level project, and save the image from that project
>>> (it is important to be in that project when saving the image).
>>>
>>> - Bert -
>>>
>>> On 16.01.2014, at 15:54, Gustavo Duarte <[hidden email]>
>>> wrote:
>>>
>>>> Hi Georg,
>>>>
>>>> The xml file content is:
>>>>
>>>> <?xml version="1.0"?>
>>>> <gconf>
>>>>         <entry name="color" mtime="1389708067" type="string">
>>>>                 <stringvalue>#9A5200,#FF2B34</stringvalue>
>>>>         </entry>
>>>>
>>>>         <entry name="birth_timestamp" mtime="1389708044" type="int"
>>>> value="-849347955"/>
>>>>
>>>>         <entry name="ip" mtime="1389708044" type="string">
>>>>                 <stringvalue>1.2.3.4</stringvalue>
>>>>         </entry>
>>>>
>>>>         <entry name="SugarBuddyOwner" mtime="1389708044"
>>>> type="string">
>>>>                 <stringvalue>1234</stringvalue>
>>>>         </entry>
>>>>
>>>>         <entry name="nick" mtime="1389708044" type="string">
>>>>                 <stringvalue>estudiante</stringvalue>
>>>>         </entry>
>>>> </gconf>
>>>>
>>>> I don't know much about xml format, but seemingly it hasn't XML schema
>>>> specification, right ?
>>>>
>>>>
>>>> On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann
>>>> <[hidden email]> wrote:
>>>>
>>>> Am 16.01.2014 um 13:10 schrieb Gustavo Duarte
>>>> <[hidden email]>:
>>>>
>>>>> I guess that XMLDOMParser doesn't support the xml line format:
>>>>> <entry name="birth_timestamp" mtime="1389708044" type="int"
>>>>> value="-849347955"/>.
>>>>>
>>>>> I don't know much about xml format, but i think that is valid format
>>>>> entry, so XMLDOMParser has bug.
>>>>
>>>>
>>>> Whether the bug is in the parser or the file depends on the XML schema
>>>> specified in the file.
>>>>
>>>> Kind regards
>>>> Georg
>>>
>>> - Bert -

--
Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Karl Ramberg
Hi,
Here are the list of changes since last release.

Cheers,
Karl


On Thu, Jan 23, 2014 at 4:13 AM, Edward Cherlin <[hidden email]> wrote:
Some of us, including me, will need to see the changes in the next
release so that we can apply them to the Etoys Reference Manual.
Others who want to take a look should speak up.

When can we download and test this version?

I have just wrapped up another manual, and can come back to this one now.

On Wed, January 22, 2014 3:39 pm, Bert Freudenberg wrote:
> (moving to etoys-dev)
>
> Awesome! :)
>
> - Bert -
>
> On 22.01.2014, at 20:49, karl ramberg <[hidden email]> wrote:
>
>>
>>
>>
>> On Wed, Jan 22, 2014 at 12:44 PM, Bert Freudenberg
>> <[hidden email]> wrote:
>> Karl: do you want to take a stab at doing an Etoys release? I don't have
>> the time to actually do it, but I am willing to do some hand-holding :)
>>
>> I will try. Must read up on this stuff, because it is easy to mess up.
>>
>> I think I will start by collecting the changes since last release.
>>
>> Hand holding and maybe some help with passwords is needed.
>> I have changed computers a few times and I'm not sure I the subversion
>> password.
>>
>> Cheers,
>> Karl
>>
>> - Bert -
>>
>> On 21.01.2014, at 21:52, karl ramberg <[hidden email]> wrote:
>>
>>> We have release process but it's a little complicated.
>>> http://etoys.squeak.org/svn/trunk/Documentation/Release-HowTo.txt
>>>
>>> Karl
>>>
>>>
>>> On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte
>>> <[hidden email]> wrote:
>>> Bert,
>>>
>>> I saw the commit to fix the sugar interaction was done.
>>>
>>> To generate the deb package of Etoys with the last changes, without
>>> wait for the upsream release: It is right the following procedure ?:
>>>
>>> 1) Run Etoys, and from unnamed project, update from server code.
>>> 2) Save the changes
>>> 3) Copy etoys.image and etoys.changes to my source code tree
>>> 4) Generate the deb package.
>>>
>>>
>>> My doubt, is meanly if only etoys.image and etoys.changes are needed to
>>> copy ?
>>>
>>>
>>> Thanks.
>>> Gustavo.
>>>
>>>
>>>
>>>
>>> On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte
>>> <[hidden email]> wrote:
>>> Bert, thank a ton for the fix.
>>>
>>> I added the bug to the tracker and upload the fix.
>>>
>>> http://tracker.squeakland.org/browse/SQ-1200
>>>
>>> I gonna wait, to be included on upstream.
>>>
>>> I hope procedure followed was be right.
>>>
>>> Thanks.
>>> Gustavo
>>>
>>>
>>> On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg
>>> <[hidden email]> wrote:
>>> Hi Gustavo,
>>>
>>> the problem is not in the XMLDomParser, but how it it used. Apparently
>>> the way gconf stores its values changed. Previously both numeric and
>>> string values had a separate entity inside, like you discovered. Now it
>>> appears int values are stored in a more compact way.
>>>
>>> The problem is in the SugarLauncher>>gconfPropertiesAt: method. It
>>> treats strings and int properties the same way.
>>>
>>> Instead of "entry elements first contentString" it might use "entry
>>> attributeAt: 'value' ifAbsent: [entry elements first contentString]".
>>> This should work with both the old and the new format. Here's the full
>>> method, patched (but untested):
>>>
>>> gconfPropertiesAt: aString
>>>     | dir |
>>>     "search up tree to guess home dir"
>>>     dir := Project squeakletDirectory.
>>>     [dir pathName = '/'] whileFalse: [
>>>         dir := dir containingDirectory.
>>>         [FileStream
>>>             readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
>>>             do: [:f |
>>>                 | props |
>>>                 props := Dictionary new.
>>>                 (XMLDOMParser parseDocumentFrom: f)
>>>                     tagsNamed: #entry do: [:entry |
>>>                         props at: (entry attributeAt: 'name')
>>>                             put: (entry attributeAt: 'value'
>>>                                 ifAbsent: [entry elements first contentString])].
>>>                 ^props].
>>>         ] on: FileDoesNotExistException do: [:ignore | ].
>>>     ].
>>>     ^self error: 'cannot find gconf path ', aString
>>>
>>> This document describes how to publish a fix for Etoys:
>>>
>>> http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt
>>>
>>> If you just want to fix it in the distro rather than waiting for an
>>> upstream release, you should be able to change the method, enter the
>>> hidden unnamed top-level project, and save the image from that project
>>> (it is important to be in that project when saving the image).
>>>
>>> - Bert -
>>>
>>> On 16.01.2014, at 15:54, Gustavo Duarte <[hidden email]>
>>> wrote:
>>>
>>>> Hi Georg,
>>>>
>>>> The xml file content is:
>>>>
>>>> <?xml version="1.0"?>
>>>> <gconf>
>>>>         <entry name="color" mtime="1389708067" type="string">
>>>>                 <stringvalue>#9A5200,#FF2B34</stringvalue>
>>>>         </entry>
>>>>
>>>>         <entry name="birth_timestamp" mtime="1389708044" type="int"
>>>> value="-849347955"/>
>>>>
>>>>         <entry name="ip" mtime="1389708044" type="string">
>>>>                 <stringvalue>1.2.3.4</stringvalue>
>>>>         </entry>
>>>>
>>>>         <entry name="SugarBuddyOwner" mtime="1389708044"
>>>> type="string">
>>>>                 <stringvalue>1234</stringvalue>
>>>>         </entry>
>>>>
>>>>         <entry name="nick" mtime="1389708044" type="string">
>>>>                 <stringvalue>estudiante</stringvalue>
>>>>         </entry>
>>>> </gconf>
>>>>
>>>> I don't know much about xml format, but seemingly it hasn't XML schema
>>>> specification, right ?
>>>>
>>>>
>>>> On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann
>>>> <[hidden email]> wrote:
>>>>
>>>> Am 16.01.2014 um 13:10 schrieb Gustavo Duarte
>>>> <[hidden email]>:
>>>>
>>>>> I guess that XMLDOMParser doesn't support the xml line format:
>>>>> <entry name="birth_timestamp" mtime="1389708044" type="int"
>>>>> value="-849347955"/>.
>>>>>
>>>>> I don't know much about xml format, but i think that is valid format
>>>>> entry, so XMLDOMParser has bug.
>>>>
>>>>
>>>> Whether the bug is in the parser or the file depends on the XML schema
>>>> specified in the file.
>>>>
>>>> Kind regards
>>>> Georg
>>>
>>> - Bert -

--
Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Karl Ramberg
In reply to this post by Bert Freudenberg
Hi,
There is a update called update-bf.31.mcm.mcm in the repository.

I guess we should delete that

Cheers,
Karl


On Wed, Jan 22, 2014 at 9:39 PM, Bert Freudenberg <[hidden email]> wrote:
(moving to etoys-dev)

Awesome! :)

- Bert -

On 22.01.2014, at 20:49, karl ramberg <[hidden email]> wrote:




On Wed, Jan 22, 2014 at 12:44 PM, Bert Freudenberg <[hidden email]> wrote:
Karl: do you want to take a stab at doing an Etoys release? I don't have the time to actually do it, but I am willing to do some hand-holding :)

I will try. Must read up on this stuff, because it is easy to mess up.

I think I will start by collecting the changes since last release.

Hand holding and maybe some help with passwords is needed.
I have changed computers a few times and I'm not sure I the subversion password.

Cheers,
Karl

- Bert -

On 21.01.2014, at 21:52, karl ramberg <[hidden email]> wrote:

We have release process but it's a little complicated.

Karl


On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte <[hidden email]> wrote:
Bert,

I saw the commit to fix the sugar interaction was done.

To generate the deb package of Etoys with the last changes, without wait for the upsream release: It is right the following procedure ?:

1) Run Etoys, and from unnamed project, update from server code.
2) Save the changes
3) Copy etoys.image and etoys.changes to my source code tree
4) Generate the deb package.


My doubt, is meanly if only etoys.image and etoys.changes are needed to copy ?


Thanks.
Gustavo.




On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte <[hidden email]> wrote:
Bert, thank a ton for the fix.

I added the bug to the tracker and upload the fix.


I gonna wait, to be included on upstream.

I hope procedure followed was be right.

Thanks.
Gustavo


On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:
Hi Gustavo,

the problem is not in the XMLDomParser, but how it it used. Apparently the way gconf stores its values changed. Previously both numeric and string values had a separate entity inside, like you discovered. Now it appears int values are stored in a more compact way.

The problem is in the SugarLauncher>>gconfPropertiesAt: method. It treats strings and int properties the same way. 

Instead of "entry elements first contentString" it might use "entry attributeAt: 'value' ifAbsent: [entry elements first contentString]". This should work with both the old and the new format. Here's the full method, patched (but untested):

gconfPropertiesAt: aString
| dir |
"search up tree to guess home dir"
dir := Project squeakletDirectory.
[dir pathName = '/'] whileFalse: [
dir := dir containingDirectory.
[FileStream
readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
do: [:f |
| props |
props := Dictionary new.
(XMLDOMParser parseDocumentFrom: f)
tagsNamed: #entry do: [:entry |
props at: (entry attributeAt: 'name')
put: (entry attributeAt: 'value'
ifAbsent: [entry elements first contentString])].
^props].
] on: FileDoesNotExistException do: [:ignore | ].
].
^self error: 'cannot find gconf path ', aString

This document describes how to publish a fix for Etoys:


If you just want to fix it in the distro rather than waiting for an upstream release, you should be able to change the method, enter the hidden unnamed top-level project, and save the image from that project (it is important to be in that project when saving the image).

- Bert -

On 16.01.2014, at 15:54, Gustavo Duarte <[hidden email]> wrote:

Hi Georg,

The xml file content is:

<?xml version="1.0"?>
<gconf>
        <entry name="color" mtime="1389708067" type="string">
                <stringvalue>#9A5200,#FF2B34</stringvalue>
        </entry>

        <entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>

        <entry name="ip" mtime="1389708044" type="string">
                <stringvalue>1.2.3.4</stringvalue>
        </entry>

        <entry name="SugarBuddyOwner" mtime="1389708044" type="string">
                <stringvalue>1234</stringvalue>
        </entry>

        <entry name="nick" mtime="1389708044" type="string">
                <stringvalue>estudiante</stringvalue>
        </entry>
</gconf>

I don't know much about xml format, but seemingly it hasn't XML schema specification, right ? 


On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann <[hidden email]> wrote:

Am 16.01.2014 um 13:10 schrieb Gustavo Duarte <[hidden email]>:

I guess that XMLDOMParser doesn't support the xml line format: 
<entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>.

I don't know much about xml format, but i think that is valid format entry, so XMLDOMParser has bug.

Whether the bug is in the parser or the file depends on the XML schema specified in the file.

Kind regards
Georg




- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev



_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Karl Ramberg
Ok,
So i published a update to the update stream.
To test you can grab latest image and update.

I'll soon start to look at the next part of the release process.

Cheers,
Karl




On Thu, Jan 23, 2014 at 2:40 PM, karl ramberg <[hidden email]> wrote:
Hi,
There is a update called update-bf.31.mcm.mcm in the repository.

I guess we should delete that

Cheers,
Karl


On Wed, Jan 22, 2014 at 9:39 PM, Bert Freudenberg <[hidden email]> wrote:
(moving to etoys-dev)

Awesome! :)

- Bert -

On 22.01.2014, at 20:49, karl ramberg <[hidden email]> wrote:




On Wed, Jan 22, 2014 at 12:44 PM, Bert Freudenberg <[hidden email]> wrote:
Karl: do you want to take a stab at doing an Etoys release? I don't have the time to actually do it, but I am willing to do some hand-holding :)

I will try. Must read up on this stuff, because it is easy to mess up.

I think I will start by collecting the changes since last release.

Hand holding and maybe some help with passwords is needed.
I have changed computers a few times and I'm not sure I the subversion password.

Cheers,
Karl

- Bert -

On 21.01.2014, at 21:52, karl ramberg <[hidden email]> wrote:

We have release process but it's a little complicated.

Karl


On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte <[hidden email]> wrote:
Bert,

I saw the commit to fix the sugar interaction was done.

To generate the deb package of Etoys with the last changes, without wait for the upsream release: It is right the following procedure ?:

1) Run Etoys, and from unnamed project, update from server code.
2) Save the changes
3) Copy etoys.image and etoys.changes to my source code tree
4) Generate the deb package.


My doubt, is meanly if only etoys.image and etoys.changes are needed to copy ?


Thanks.
Gustavo.




On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte <[hidden email]> wrote:
Bert, thank a ton for the fix.

I added the bug to the tracker and upload the fix.


I gonna wait, to be included on upstream.

I hope procedure followed was be right.

Thanks.
Gustavo


On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:
Hi Gustavo,

the problem is not in the XMLDomParser, but how it it used. Apparently the way gconf stores its values changed. Previously both numeric and string values had a separate entity inside, like you discovered. Now it appears int values are stored in a more compact way.

The problem is in the SugarLauncher>>gconfPropertiesAt: method. It treats strings and int properties the same way. 

Instead of "entry elements first contentString" it might use "entry attributeAt: 'value' ifAbsent: [entry elements first contentString]". This should work with both the old and the new format. Here's the full method, patched (but untested):

gconfPropertiesAt: aString
| dir |
"search up tree to guess home dir"
dir := Project squeakletDirectory.
[dir pathName = '/'] whileFalse: [
dir := dir containingDirectory.
[FileStream
readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
do: [:f |
| props |
props := Dictionary new.
(XMLDOMParser parseDocumentFrom: f)
tagsNamed: #entry do: [:entry |
props at: (entry attributeAt: 'name')
put: (entry attributeAt: 'value'
ifAbsent: [entry elements first contentString])].
^props].
] on: FileDoesNotExistException do: [:ignore | ].
].
^self error: 'cannot find gconf path ', aString

This document describes how to publish a fix for Etoys:


If you just want to fix it in the distro rather than waiting for an upstream release, you should be able to change the method, enter the hidden unnamed top-level project, and save the image from that project (it is important to be in that project when saving the image).

- Bert -

On 16.01.2014, at 15:54, Gustavo Duarte <[hidden email]> wrote:

Hi Georg,

The xml file content is:

<?xml version="1.0"?>
<gconf>
        <entry name="color" mtime="1389708067" type="string">
                <stringvalue>#9A5200,#FF2B34</stringvalue>
        </entry>

        <entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>

        <entry name="ip" mtime="1389708044" type="string">
                <stringvalue>1.2.3.4</stringvalue>
        </entry>

        <entry name="SugarBuddyOwner" mtime="1389708044" type="string">
                <stringvalue>1234</stringvalue>
        </entry>

        <entry name="nick" mtime="1389708044" type="string">
                <stringvalue>estudiante</stringvalue>
        </entry>
</gconf>

I don't know much about xml format, but seemingly it hasn't XML schema specification, right ? 


On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann <[hidden email]> wrote:

Am 16.01.2014 um 13:10 schrieb Gustavo Duarte <[hidden email]>:

I guess that XMLDOMParser doesn't support the xml line format: 
<entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>.

I don't know much about xml format, but i think that is valid format entry, so XMLDOMParser has bug.

Whether the bug is in the parser or the file depends on the XML schema specified in the file.

Kind regards
Georg




- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev




_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Markus Schlager-2
In reply to this post by Karl Ramberg
On Thu, 23 Jan 2014, karl ramberg wrote:

> Here are the list of changes since last release.
> http://etoys.squeak.org/svn/trunk/Etoys/NEWS

Is there any chance to get SQ-1116 and SQ-1146 fixed?

These two break projects created with Etoys-4 and are really annoying if
you are e.g. doing animations and would like to hide the costume holder or
using keypress morphs you'd like to hide in flap.

Markus
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Bert Freudenberg
In reply to this post by Karl Ramberg

On 23.01.2014, at 17:56, karl ramberg <[hidden email]> wrote:

Ok,
So i published a update to the update stream.
To test you can grab latest image and update.

I'll soon start to look at the next part of the release process.

Cheers,
Karl

Worked fine for me. Great!

- Bert -






On Thu, Jan 23, 2014 at 2:40 PM, karl ramberg <[hidden email]> wrote:
Hi,
There is a update called update-bf.31.mcm.mcm in the repository.

I guess we should delete that

Cheers,
Karl


On Wed, Jan 22, 2014 at 9:39 PM, Bert Freudenberg <[hidden email]> wrote:
(moving to etoys-dev)

Awesome! :)

- Bert -

On 22.01.2014, at 20:49, karl ramberg <[hidden email]> wrote:




On Wed, Jan 22, 2014 at 12:44 PM, Bert Freudenberg <[hidden email]> wrote:
Karl: do you want to take a stab at doing an Etoys release? I don't have the time to actually do it, but I am willing to do some hand-holding :)

I will try. Must read up on this stuff, because it is easy to mess up.

I think I will start by collecting the changes since last release.

Hand holding and maybe some help with passwords is needed.
I have changed computers a few times and I'm not sure I the subversion password.

Cheers,
Karl

- Bert -

On 21.01.2014, at 21:52, karl ramberg <[hidden email]> wrote:

We have release process but it's a little complicated.

Karl


On Mon, Jan 20, 2014 at 5:34 PM, Gustavo Duarte <[hidden email]> wrote:
Bert,

I saw the commit to fix the sugar interaction was done.

To generate the deb package of Etoys with the last changes, without wait for the upsream release: It is right the following procedure ?:

1) Run Etoys, and from unnamed project, update from server code.
2) Save the changes
3) Copy etoys.image and etoys.changes to my source code tree
4) Generate the deb package.


My doubt, is meanly if only etoys.image and etoys.changes are needed to copy ?


Thanks.
Gustavo.




On Fri, Jan 17, 2014 at 5:52 PM, Gustavo Duarte <[hidden email]> wrote:
Bert, thank a ton for the fix.

I added the bug to the tracker and upload the fix.


I gonna wait, to be included on upstream.

I hope procedure followed was be right.

Thanks.
Gustavo


On Fri, Jan 17, 2014 at 9:51 AM, Bert Freudenberg <[hidden email]> wrote:
Hi Gustavo,

the problem is not in the XMLDomParser, but how it it used. Apparently the way gconf stores its values changed. Previously both numeric and string values had a separate entity inside, like you discovered. Now it appears int values are stored in a more compact way.

The problem is in the SugarLauncher>>gconfPropertiesAt: method. It treats strings and int properties the same way. 

Instead of "entry elements first contentString" it might use "entry attributeAt: 'value' ifAbsent: [entry elements first contentString]". This should work with both the old and the new format. Here's the full method, patched (but untested):

gconfPropertiesAt: aString
| dir |
"search up tree to guess home dir"
dir := Project squeakletDirectory.
[dir pathName = '/'] whileFalse: [
dir := dir containingDirectory.
[FileStream
readOnlyFileNamed: dir pathName, '/.gconf', aString, '/%gconf.xml'
do: [:f |
| props |
props := Dictionary new.
(XMLDOMParser parseDocumentFrom: f)
tagsNamed: #entry do: [:entry |
props at: (entry attributeAt: 'name')
put: (entry attributeAt: 'value'
ifAbsent: [entry elements first contentString])].
^props].
] on: FileDoesNotExistException do: [:ignore | ].
].
^self error: 'cannot find gconf path ', aString

This document describes how to publish a fix for Etoys:


If you just want to fix it in the distro rather than waiting for an upstream release, you should be able to change the method, enter the hidden unnamed top-level project, and save the image from that project (it is important to be in that project when saving the image).

- Bert -

On 16.01.2014, at 15:54, Gustavo Duarte <[hidden email]> wrote:

Hi Georg,

The xml file content is:

<?xml version="1.0"?>
<gconf>
        <entry name="color" mtime="1389708067" type="string">
                <stringvalue>#9A5200,#FF2B34</stringvalue>
        </entry>

        <entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>

        <entry name="ip" mtime="1389708044" type="string">
                <stringvalue>1.2.3.4</stringvalue>
        </entry>

        <entry name="SugarBuddyOwner" mtime="1389708044" type="string">
                <stringvalue>1234</stringvalue>
        </entry>

        <entry name="nick" mtime="1389708044" type="string">
                <stringvalue>estudiante</stringvalue>
        </entry>
</gconf>

I don't know much about xml format, but seemingly it hasn't XML schema specification, right ? 


On Thu, Jan 16, 2014 at 11:11 AM, Georg Gollmann <[hidden email]> wrote:

Am 16.01.2014 um 13:10 schrieb Gustavo Duarte <[hidden email]>:

I guess that XMLDOMParser doesn't support the xml line format: 
<entry name="birth_timestamp" mtime="1389708044" type="int" value="-849347955"/>.

I don't know much about xml format, but i think that is valid format entry, so XMLDOMParser has bug.

Whether the bug is in the parser or the file depends on the XML schema specified in the file.

Kind regards
Georg




_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next Etoys release

Karl Ramberg
In reply to this post by Markus Schlager-2
I commented on SQ-1116 on the tracker.
I think current behavior is preferable and consistent.

 SQ-1146 is a little more work to fix and I think it's quite important to fix it. 
But we do not have a fix available yet.

Cheers,
Karl 


On Sun, Jan 26, 2014 at 1:33 AM, Markus Schlager <[hidden email]> wrote:
On Thu, 23 Jan 2014, karl ramberg wrote:

Here are the list of changes since last release.
http://etoys.squeak.org/svn/trunk/Etoys/NEWS

Is there any chance to get SQ-1116 and SQ-1146 fixed?

These two break projects created with Etoys-4 and are really annoying if you are e.g. doing animations and would like to hide the costume holder or using keypress morphs you'd like to hide in flap.

Markus


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Loading...