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 <gduarte at activitycentral.com
> 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 <bert at freudenbergs.de>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 <gduarte at activitycentral.com>
>> 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 <
>> gollmann at zid.tuwien.ac.at> wrote:
>>
>>>
>>> Am 16.01.2014 um 13:10 schrieb Gustavo Duarte <
>>> gduarte at activitycentral.com>:
>>>
>>>  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 -
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140120/1f9a77a6/attachment.htm