Re: [Sugar-devel] [UKids] Re: [Announcement] Sugarizer v0.8 is available for your device

[Bert Freudenberg]

Steve,

append "&document=url-for-project" to the URL. e.g.

https://squeak.js.org/etoys/#fullscreen&document=http://www.squeakland.org/content/showcase/everyone/accounts/mrsteve/Balance%20Scale.014.pr

- Bert -

On Wed, Jan 11, 2017 at 3:06 AM, Steve Thomas  wrote:

>
> Bert,
>
> Works on Chromebook.
>
> Is there anyway to open a Etoys project I already created? Perhaps as a
> parameter in the URL pointing to somewhere I uploaded the file?
>
> Thanks,
> Stephen
>
> On Sun, Jan 8, 2017 at 3:39 PM, Bert Freudenberg 
> wrote:
>
>> Hi Steve,
>>
>> have you tried plain Etoys on a Chromebook?
>>
>> https://squeak.js.org/etoys/#fullscreen
>>
>> Also, we have an experimental Chrome app here:
>> https://chrome.google.com/webstore/detail/etoys/pfddkmhbbphp
>> elipkocbhmgbofdoagpi
>>
>> - Bert -
>>
>> On Sat, Jan 7, 2017 at 10:46 PM, Lionel Laské 
>> wrote:
>>
>>>
>>> Hi Steve,
>>>
>>> Yes, unfortunately EToys could have some limitation because it need to
>>> load a full VM to run, it's why it not appear as favorite by default.
>>> I'm CC'ed Bert that could help you on it.
>>>
>>> Regards.
>>>
>>>   Lionel.
>>>
>>>
>>> 2017-01-06 23:21 GMT+01:00 Steve Thomas :
>>>
>>>> Okay, I tried restarting Chrome a second time and now Etoys opens on
>>>> Mac. But had an issue saving. I'll investigate further.
>>>>
>>>> Hoping to get Etoys (et al) working on Chromebook's so I can get
>>>> teachers in my kids school to start using it.
>>>>
>>>> Cheers,
>>>> Stephen
>>>>
>>>> On Fri, Jan 6, 2017 at 5:15 PM, Steve Thomas 
>>>> wrote:
>>>>
>>>>> Lionel,
>>>>>
>>>>> This is great work, thank you.
>>>>>
>>>>> Ran into a few issues trying to run Etoys (Turtle Blocks seems to run
>>>>> just fine), :
>>>>>
>>>>>1. Added Chrome extension but Etoys did not run, just got black
>>>>>screen.
>>>>>   1. Tried on Mac and Windows using latest Chrome, waited about 5
>>>>>   minutes+
>>>>>2. Also downloaded from iTunes onto my Mac and had same issue
>>>>>
>>>>> Thanks,
>>>>> Stephen
>>>>>
>>>>>
>
>
> --
>
> To some of us, writing computer programs is a fascinating game. A program
> is a building of thought. It is costless to build, weightless, growing
> easily under our typing hands. If we get carried away, its size and
> complexity will grow out of control, confusing even the one who created it.
> This is the main problem of programming. It is why so much of today's
> software tends to crash, fail, screw up.
>
> When a program works, it is beautiful. The art of programming is the skill
> of controlling complexity. The great program is subdued, made simple in its
> complexity.
>
> - Martin Harverbeke (from Eloquent JavaScript
> <http://eloquentjavascript.net/index.html>)
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [UKids] Re: [Announcement] Sugarizer v0.8 is available for your device

[Bert Freudenberg]

Hi Steve,

have you tried plain Etoys on a Chromebook?

https://squeak.js.org/etoys/#fullscreen

Also, we have an experimental Chrome app here:
https://chrome.google.com/webstore/detail/etoys/
pfddkmhbbphpelipkocbhmgbofdoagpi

- Bert -

On Sat, Jan 7, 2017 at 10:46 PM, Lionel Laské 
wrote:

>
> Hi Steve,
>
> Yes, unfortunately EToys could have some limitation because it need to
> load a full VM to run, it's why it not appear as favorite by default.
> I'm CC'ed Bert that could help you on it.
>
> Regards.
>
>   Lionel.
>
>
> 2017-01-06 23:21 GMT+01:00 Steve Thomas :
>
>> Okay, I tried restarting Chrome a second time and now Etoys opens on Mac.
>> But had an issue saving. I'll investigate further.
>>
>> Hoping to get Etoys (et al) working on Chromebook's so I can get teachers
>> in my kids school to start using it.
>>
>> Cheers,
>> Stephen
>>
>> On Fri, Jan 6, 2017 at 5:15 PM, Steve Thomas 
>> wrote:
>>
>>> Lionel,
>>>
>>> This is great work, thank you.
>>>
>>> Ran into a few issues trying to run Etoys (Turtle Blocks seems to run
>>> just fine), :
>>>
>>>1. Added Chrome extension but Etoys did not run, just got black
>>>screen.
>>>   1. Tried on Mac and Windows using latest Chrome, waited about 5
>>>   minutes+
>>>2. Also downloaded from iTunes onto my Mac and had same issue
>>>
>>> Thanks,
>>> Stephen
>>>
>>>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Bert Freudenberg]

On 18.05.2016, at 17:01, Dave Crossland  wrote:
> On 18 May 2016 at 10:54, Bert Freudenberg  <mailto:b...@freudenbergs.de>> wrote:
> On 18.05.2016, at 16:26, Dave Crossland  <mailto:d...@lab6.com>> wrote:
>> 
>> Hi
>> 
>> On 18 May 2016 at 09:57, Tony Anderson > <mailto:tony_ander...@usa.net>> wrote:
>> Its an educational project. An example is 
>> https://github.com/ezequielpereira/Bridge 
>> <https://github.com/ezequielpereira/Bridge>. This version of the 
>> Bridge-activity was developed as part of GCI. 
>> The zip downloaded from github is named Bridge-master.zip. I copied the zip 
>> to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a 
>> proper xo bundle which installed and ran. 
>> 
>> Sounds good :)
>>  
>> However, it failed to start: import error lib/box2d_32/_Box2D.so.
>> 
>> Is that error a bug in the program?
> 
> More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries, while 
> older XOs used x86. The activity bundle would have to include .so files for 
> each supported architecture. I don’t think we ever extended the bundle 
> structure to properly handle multi-arch, it was designed for 
> platform-independent code like Python.
> 
> Okay cool :)
> 
> Can the bundle structure deal with this in an ad-hoc way, or does it need 
> changes to the Sugar Desktop platform itself? 

The bundle can have arbitrary library folders, but the activity would need to 
implement selecting the right binary for the current architecture.

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Bert Freudenberg]

On 18.05.2016, at 16:26, Dave Crossland  wrote:
> 
> Hi
> 
> On 18 May 2016 at 09:57, Tony Anderson  > wrote:
> Its an educational project. An example is 
> https://github.com/ezequielpereira/Bridge 
> . This version of the 
> Bridge-activity was developed as part of GCI. 
> The zip downloaded from github is named Bridge-master.zip. I copied the zip 
> to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a 
> proper xo bundle which installed and ran.
> 
> Sounds good :)
>  
> However, it failed to start: import error lib/box2d_32/_Box2D.so.
> 
> Is that error a bug in the program?

More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries, while 
older XOs used x86. The activity bundle would have to include .so files for 
each supported architecture. I don’t think we ever extended the bundle 
structure to properly handle multi-arch, it was designed for 
platform-independent code like Python.

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Javascript Activities

[Bert Freudenberg]

On 24.04.2016, at 06:41, Dave Crossland  wrote:
> On 23 April 2016 at 22:52,  > wrote:
> E-Toys is just a black screen on my Note 5.
> 
> That's a pity! Etoys seems to me to be one of the most important yet 
> undervalued Sugar Activities :) 

Pulling in a newer version of SqueakJS might help with that.

> The "Squeakers DVD" in http://squeakland.org/resources/audioVisual/ 
>  is cool, shows how powerful it 
> can be for learning! :)

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Active development

[Bert Freudenberg]

On 18.04.2016, at 17:28, Dave Crossland  wrote:
> 
> Hi
> I spent a lot of time yesterday reading about the history of smalltalk, and 
> it seems undervalued. 
> 
> http://activities.sugarlabs.org/en-US/sugar/search?q=squeak&cat=all 
>  only 
> produces 1 result, etoys. 

When OLPC development was started, Squeak was indeed considered as an 
implementation language, but ultimately Python was selected in the hope of 
tapping into the larger open-source community (the Smalltalk developer 
community is quite small compared to Python users). Alan even gave a keynote at 
Pycon but I don’t think it actually lead to a big influx of developers for 
Sugar.

Etoys has been pretty much the only non-Python activity for a very long time 
(I’m not sure if there is another one nowadays). See
https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API 


> Are any other activities written in squeak?

Very few, but yes:

http://activities.sugarlabs.org/en-US/sugar/addon/4054 

http://activities.sugarlabs.org/en-US/sugar/addon/4235 


… and some more at:
http://hpi.uni-potsdam.de/hirschfeld/projects/olpc/

> Can other activities be made within etoys? 

In Etoys you create projects, and there is a way to make a Sugar activity from 
a project, but that is more of an experimental feature, we never added a proper 
UI:


- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [SLOB] Meeting reminder

[Bert Freudenberg]

On 05.10.2015, at 16:23, Adam Holt  wrote:
> 
> On Mon, Oct 5, 2015 at 7:05 PM, James Cameron  <mailto:qu...@laptop.org>> wrote:
> G'day Walter,
> 
> It has emerged that 23 UTC is not 6pm Boston.
> 
> Could meetings be called using only UTC please?  ;-)
> 
> If so use:
> http://google.com/search?q=utc+time <http://google.com/search?q=utc+time>
> 
> I like Bert Freudenberg prefer to pick 1 real city where many of us Actually 
> Live, whichever one does not matter -- but including that 1 single link 
> (whichever) keeps everyone honest:
> http://google.com/search?q=nyc+time <http://google.com/search?q=nyc+time>
> http://google.com/search?q=lima+time <http://google.com/search?q=lima+time>
> http://google.com/search?q=boston+time 
> <http://google.com/search?q=boston+time>
> http://google.com/search?q=montevideo+time 
> <http://google.com/search?q=montevideo+time>
I’m pretty sure that as an ombudsperson I should step in only when there is a 
conflict ;)

But I’ll say that we have had good experience sending meeting announcements 
with a link to the time&date web site, showing the desired time as local plus a 
gazillion other time zones. Here’s what it would have looked like for Boston 
6pm:

http://www.timeanddate.com/worldclock/fixedtime.html?msg=SLOBs+Meeting&iso=20151005T18&p1=43
 
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=SLOBs+Meeting&iso=20151005T18&p1=43>

At the bottom it even lists the time in UTC for James ;) 

- Bert -

> On Sun, Oct 04, 2015 at 11:00:29AM -0400, Walter Bender wrote:
> > Tomorrow (5 October) is the first Monday of the month. We will have a
> > meeting at 23:00 UTC (6PM in Boston; 4PM in Managua; 6PM in
> > Port-au-Prince; 7PM in Asuncion; 8PM in Montevideo; 8PM in BA;
> > midnight in Paris; 4:30 AM in Dehli; 10AM (+1) in Sydney).
> >
> > Please join us.
> >
> > regards.
> >
> > -walter
> > --
> > Walter Bender
> > Sugar Labs
> > http://www.sugarlabs.org <http://www.sugarlabs.org/>
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org <mailto:Sugar-devel@lists.sugarlabs.org>
> > http://lists.sugarlabs.org/listinfo/sugar-devel 
> > <http://lists.sugarlabs.org/listinfo/sugar-devel>
> 
> --
> James Cameron
> http://quozl.linux.org.au/ <http://quozl.linux.org.au/>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org <mailto:i...@lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/iaep
> 
> -- 
>  <http://lists.sugarlabs.org/listinfo/iaep> 
> <http://lists.sugarlabs.org/listinfo/iaep>Unsung Heroes of OLPC, interviewed 
> live @  <http://lists.sugarlabs.org/listinfo/iaep>http://unleashkids.org 
> <http://unleashkids.org/> !
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel






smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Planning for the future (Samuel Greenfeld)

[Bert Freudenberg]

On 25.02.2015, at 13:22, Nick Doiron  wrote:
> 
> I've worked with the project for some time, as a developer, teacher, and 
> teacher-trainer.
> 
> There have been triumphs and setbacks in the past, but I can't escape this 
> observation: when people have a choice, they choose not to use Sugar.  For 
> many schools, they have what was donated and there is no choice. When OLPC 
> started, Android was an independent concept for a feature phone and not a 
> choice for anyone. But if members of our community are talking about a major 
> project in today's world, examine why the wider world isn't using Sugar at 
> the same level that they adopt other edu-tech, like Scratch. Time and time 
> again, local teachers are doing everything we ask, and our true limit is the 
> technology and UX.
> 
> As a developer, I have lost track of which of my activities might run on 
> modern Sugar. I've seen simple UIs and browser-based activities stop working, 
> not because of shaky code, but because dropdown menus got deprecated, or 
> browser embedding was switched out with a different library. There are 
> reasons behind these code changes, like touch-enabled UI, but were these 
> reasons so real?  At the end of all this continuing development, when I use 
> an XO-1 in Haiti, I see the same Sugar that we used in 2011, but with fewer 
> working activities.
> 
> I am interested in the future of Sugar in the same way that I'm interested in 
> the future of television. The next big thing is not a revision of the old, 
> but something very new, something more attuned to the web and open source 
> ecosystem as it exists today.
> 
> -- Nick Doiron


+1

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Testing Sugar Activities Fedora-Live-SoaS-i686-21_Beta-4

[Bert Freudenberg]

On 23.11.2014, at 20:25, Iain Brown Douglas  wrote:
> 
> On Sat, 2014-11-22 at 16:16 +0100, Bert Freudenberg wrote:
>>> On 22.11.2014, at 15:15, Jean THIERY  wrote:
>>> 
>>> EToys-116 displays
>>> « Cannot find image file: squeak, did you run 'initsqueak -m'? »
>>> After clicking on this message,
>>> the screen is filled by cars and is not usable.
>> 
>> That looks weird ... does it work if you run "etoys" from the Terminal 
>> activity?
> 
> Thank you Bert for your reply,
> 
> Yes, Etoys starts ok when I simply:
> 
> run "etoys" from the Terminal activity.
> 
> Why is this? what is wrong with the Sugar launcher?

I have no idea. The error message should actually mean it doesn't work at all. 
But you're saying it is running, albeit incorrectly ("screen filled with 
cars"). Maybe those two are unrelated. The latter might have to do with being 
run full-screen vs. windowed. We didn't change anything in Etoys so I think it 
must be some environmental change?

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Testing Sugar Activities Fedora-Live-SoaS-i686-21_Beta-4

[Bert Freudenberg]

> On 22.11.2014, at 15:15, Jean THIERY  wrote:
> 
> EToys-116 displays
> « Cannot find image file: squeak, did you run 'initsqueak -m'? »
> After clicking on this message,
> the screen is filled by cars and is not usable.

That looks weird ... does it work if you run "etoys" from the Terminal activity?

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Announcement] Sugarizer v0.5 is available for your device

[Bert Freudenberg]

On 17.10.2014, at 08:25, Lionel Laské  wrote:

> Hi all,
>  
> I'm proud to announce the fifth version (0.5) of Sugarizer, a taste of Sugar 
> for any device.
>  
> http://sugarizer.org

Very nice!

> New Etoys activity (beta)

I've made some good progress on this since you grabbed a copy, you may want to 
update :)
http://bertfreudenberg.github.io/SqueakJS/etoys/

There are quitSqueak() and onQuit() functions now which should make it easier 
for you to hook it up. See for example
https://github.com/bertfreudenberg/SqueakJS/blob/master/benchmark/benchmark.js

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] From GConf to GSettings

[Bert Freudenberg]

> On 26.12.2013, at 18:02, Emil Dudev  wrote:
> 
> As GConf is deprecated, it should be replaced by GSettings.
> 
> I've made a patch that will change most of the code to use GSettings.
> (I'm not sure how to include the link, as it will cause the mail to be
> sent to the spam folder).
> 
> Moving to GSettings is not something easy. The biggest issue is the
> compatibility of the activities.
> How should it be handled?
> I'm not sure how many activities use GConf. I was able to find only 3:
> read and write (using sugar's speech settings), and browse. But I'm
> sure there are more activities.

Etoys reads the Sugar nick name and colors from the .gconf files. 

- Bert -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ANN] SqueakJS

[Bert Freudenberg]

Thank you! :)

For those who don't want to read the explanations, just see the demo:

http://bertfreudenberg.github.io/SqueakJS/demo/simple.html

- Bert -

On 2013-12-23, at 15:46, Gonzalo Odiard  wrote:

> Impressive!
> 
> Gonzalo
> 
> 
> On Fri, Dec 20, 2013 at 6:30 PM, Bert Freudenberg  
> wrote:
> Hi folks,
> 
> this is still far from running Etoys in the browser, but it does work 
> surprisingly well:
> 
> http://croquetweak.blogspot.de/2013/12/squeakjs-lively-squeak-vm.html
> 
> Have a great Christmas!
> 
> - Bert -



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ANN] SqueakJS

[Bert Freudenberg]

Hi folks,

this is still far from running Etoys in the browser, but it does work 
surprisingly well:

http://croquetweak.blogspot.de/2013/12/squeakjs-lively-squeak-vm.html

Have a great Christmas!

- Bert - 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys in Sugar was: SoaS v10 testing and a few minor issues with 0.100

[Bert Freudenberg]

On 19.11.2013, at 17:33, Peter Robinson  wrote:

>>> On Tue, Nov 19, 2013 at 12:39 PM, Peter Robinson  
>>> wrote:
>>> On Tue, Nov 19, 2013 at 5:33 PM, Gonzalo Odiard  wrote:
>> 
>> - The "eToys" activity (version 116) does not start properly
>>  then displays
>>  « cannot find image file: squeak, did you run 'inisqueak-m' ? »
>>> 
>>> This was ticketed here,
>>> https://bugs.sugarlabs.org/ticket/4415
>> 
>> Ah. I even commented on that, apparently :)
>> 
> 
> The eToys developers are basically unresponsive, I'm in two minds
> whether we even bother to ship it because they can't be bothered doing
> things like updating to the latest sugar by migrating away from
> sugar-presence-service/ which was deprecated a long time ago.
>> 
>> This is a rather non-trivial change to Etoys, whereas keeping the 
>> sugar-presence-service emulation around is pretty trivial.
>> 
>> Yes it would be good to do it, no I have not had the time. Nor someone else.
> 
> You've had 3 odd years.

Yes. It never got to the top of my priority list. Mea culpa.

>> But made Etoys work even if the emulated presence service is not around. So 
>> everything except collaborating should work fine.
> 
> How? what release, how was it communicated?

Etoys 5. We last talked about it on the SoaS list on June 7 2012. I wrote in 
reply to Manuel Kaufmann:

"With regard to sharing, the only difference between Etoys 4 and Etoys 5 is 
that 
Etoys 5 will still work if the presence service fails, whereas Etoys 4 showed 
an error on startup."

 But this looks like a different problem, right?
>> 
>> Yes.
> 
> Care to elaborate?

The startup error "cannot find image file: squeak" is not related to the 
presence service at all, because it happens before Etoys is even started up. 
So, "yes, this looks like a different problem". But without further information 
I can not elaborate, unfortunately.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys in Sugar was: SoaS v10 testing and a few minor issues with 0.100

[Bert Freudenberg]

On 19.11.2013, at 12:07, Frederick Grose  wrote:

> On Tue, Nov 19, 2013 at 12:39 PM, Peter Robinson  wrote:
> On Tue, Nov 19, 2013 at 5:33 PM, Gonzalo Odiard  wrote:
> >> >
> >> > - The "eToys" activity (version 116) does not start properly
> >> >   then displays
> >> >   « cannot find image file: squeak, did you run 'inisqueak-m' ? »
> 
> This was ticketed here,
> https://bugs.sugarlabs.org/ticket/4415

Ah. I even commented on that, apparently :)

> >>
> >> The eToys developers are basically unresponsive, I'm in two minds
> >> whether we even bother to ship it because they can't be bothered doing
> >> things like updating to the latest sugar by migrating away from
> >> sugar-presence-service/ which was deprecated a long time ago.

This is a rather non-trivial change to Etoys, whereas keeping the 
sugar-presence-service emulation around is pretty trivial.

Yes it would be good to do it, no I have not had the time. Nor someone else.

But made Etoys work even if the emulated presence service is not around. So 
everything except collaborating should work fine.

> > But this looks like a different problem, right?

Yes.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Translating etoys home screen

[Bert Freudenberg]

On 08.10.2013, at 22:56, Daniel Drake  wrote:

> Hi Bert,
> 
> Could you advise on how we could translate the etoys home screen to Armenian?
> 
> I see:
> 
> http://forum.world.st/How-to-translate-strings-in-Home-pr-td3527757.html
> 
> However the crucial "how to translate" link there is broken.

Ah, that's on the old wiki:
http://oldwiki.squeakland.org/display/sq/How+to+translate+Projects

Would be great if someone could make a more thorough step-by-step guide, like 
the one for the help system:

http://oldwiki.squeakland.org/display/sq/How+to+translate+the+Quick+Guides

However, these are different in that a separate project is used per language 
and loaded on demand, whereas for the home-screen (and projects in general) all 
the translations live in a single project together.

> The first step in this translation would be to generate a list of
> strings so that I can pass them on for translation.


Yes. Unfortunately our in-project translation is not set up for gettext, and 
the home screen is just a project as far as the system is concerned.

Once you have changed the home screen project, you need to switch to the hidden 
"Unnamed1" project (via ctrl-shift-w) and save the etoys image.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] How to deploy the webactivity libraries

[Bert Freudenberg]

On 2013-05-29, at 16:46, Daniel Drake  wrote:

> In other words, I imagine that for activities that meet a certain
> level of complexity/functionality, there will commonly be some point
> at which they cross the line and start depending something specific in
> the underlying system, which breaks any dreams of self contained
> activities. If I'm right, maybe we should consider dropping that as a
> realistic possibility for a reliable experience.

Not being able to achieve 100% independence is no reason to ditch the idea 
completely. 

Bundling as much as possible in an activity keeps the interface between the 
activity and the outside world very small. There are a lot fewer things that 
can go wrong. And that's a Good Thing :)

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Collaboration API (was Re: HTML5 Activities page on the Wiki)

[Bert Freudenberg]

On 2013-04-30, at 14:13, Daniel Narvaez  wrote:

> On 30 April 2013 14:00, Bert Freudenberg  wrote:
>> It is indeed the implementation details I'm talking about. The Javascript 
>> API could use an identical Python API. And that API could then be used both 
>> by Javascript activities and other activities, too. This would simplify the 
>> development process for all, because activity developers would not have to 
>> talk to Telepathy directly.
>> 
>> You have to implement the new API anyway. The question is simply, where to 
>> put that code. If you put it in the Sugar Shell and expose it via DBus, it 
>> will be available to all activity developers. The Javascript API would 
>> simply be a very thin layer that use it. OTOH, if you put that code only 
>> into the HTML activity support, you now have created two different ways to 
>> implement collaboration in Sugar. You will have to document separately, 
>> learn separately, maintain separately.
>> 
>> One problem with that approach is that we don't have a way for javascript to 
>> talk dbus directly. We could perhaps build one but it's probably going to be 
>> non trivial.

If you google "javascript dbus" you will find several bindings. But since you 
are implementing the HTML activity framework in Python anyway you wouldn't even 
need that.

> It's also worrying that one of the reason to deprecate the old Presence 
> Service seems to have been avoiding the extra IPC layer, which we would be 
> reintroducing here. 

So how would your Javascript API work, if not via IPC?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Collaboration API (was Re: HTML5 Activities page on the Wiki)

[Bert Freudenberg]

On 2013-04-30, at 12:54, Daniel Narvaez  wrote:

> On 30 April 2013 12:35, Bert Freudenberg  wrote:
>> Will that new Collaboration API be made available to non-HTML activities, 
>> too? And how will it be different from the deprecated Presence Service?
> 
> No, the idea is that the public API layer will be javascript,

Of course.

> the rest being internal implementation detail.

It is indeed the implementation details I'm talking about. The Javascript API 
could use an identical Python API. And that API could then be used both by 
Javascript activities and other activities, too. This would simplify the 
development process for all, because activity developers would not have to talk 
to Telepathy directly.

You have to implement the new API anyway. The question is simply, where to put 
that code. If you put it in the Sugar Shell and expose it via DBus, it will be 
available to all activity developers. The Javascript API would simply be a very 
thin layer that use it. OTOH, if you put that code only into the HTML activity 
support, you now have created two different ways to implement collaboration in 
Sugar. You will have to document separately, learn separately, maintain 
separately. 

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Collaboration API (was Re: HTML5 Activities page on the Wiki)

[Bert Freudenberg]

On 2013-04-30, at 12:23, Daniel Narvaez  wrote:

> Hi Lionel,
> 
> nice write up. 
> 
> the only thing I'd change is probably to use Collaboration or something in 
> place of Telepathy. Just to make it clear we are after a generic API that can 
> work on other platforms too, rather than just wrapping telepathy.

Will that new Collaboration API be made available to non-HTML activities, too? 
And how will it be different from the deprecated Presence Service?

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Fwd: [ANN] Four new OLPC Games by the Software Architecture Group

[Bert Freudenberg]

Begin forwarded message:

> From: Michael Perscheid 
> Subject:ANN] Four new OLPC Games by the Software Architecture Group
> Date: 16. April 2013 08:22:27 GMT-07:00
> To: Squeak in Germany / Squeak in Deutschland 
> 
> Reply-To: Squeak in Germany / Squeak in Deutschland 
> 
> 
> Hi all,
> 
> we'd like to announce that we published four new games for the OLPC/XO laptop 
> (also available 
> for Standard Squeak, MIT license). They have been developed by students in 
> the last semesters 
> of our software architecture lecture (Hasso-Plattner-Institute, University of 
> Potsdam).
> 
> http://www.hpi.uni-potsdam.de/swa/projects/olpc/index.html
> (or: http://www.hpi.uni-potsdam.de/hirschfeld/projects/olpc/index.html)
> 
> In particular, we thank the following students for their course work and 
> Matthias Springer for 
> porting the projects to the XO. 
> 
> BroBreakout
>   Fabio Niephaus, Daniel Werner, Philipp Otto, Frank Blechschmidt
> PetConnect
>   Jaqueline Pollak, Daniel Neuschaefer-Rube, Jakob Reschke, Judith 
> Hartmann
> BDBoulderDash
>   Johannes Koch, Tim Friedrich, Johannes Villmow, Felix Wolff
> SpaceCleanup
>   Kai Fabian, Dominik Moritz, Malte Swart, Matthias Springer
> 
> More games are coming soon...
> 
> Best,
> Michael
> 
> ---
> Michael Perscheid
> michaelpersch...@googlemail.com
> 
> http://www.michaelperscheid.de/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available

[Bert Freudenberg]

On 15.04.2013, at 07:53, Daniel Drake  wrote:

> Hi,
> 
> 
> On Wed, Mar 27, 2013 at 1:10 PM, Daniel Drake  wrote:
>> Extend the sound backend selection code to consider using ALSA.
>> On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x.
>> It also fixes XO-4 sound recording which was not working on any previous
>> version.
> 
> Ping, any news here?
> 
> Thanks
> Daniel


Ah, I'm sorry, didn't get to it yet. Thanks for the reminder!

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar future

[Bert Freudenberg]

On 12.04.2013, at 15:39, Caryl Bigenho  wrote:

> O.K. So... now it is time to "divide and conquer!"

Is it?

> That is... divide the work up into doable little projects and conquer the 
> huge task of getting Sugar Activities onto Android and possibly other 
> platforms.

IMHO the individual activities are *not* what makes Sugar such a compelling 
proposition. Sure, having some of them as apps on other platforms would be 
nice. But isn't collaborating and sharing at the heart of Sugar? The Journal as 
central UI? The effortless discovery of your peers in the neighborhood view? 
Etc? *That* experience would have to be ported to another platform first, and 
then the activities can follow. Otherwise, it's just a bunch of random apps, of 
which there are plenty already in the various app stores.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fwd: Unable to exit Etoys.

[Bert Freudenberg]

On 2013-02-13, at 18:09, Rafael Ortiz  wrote:

> On Wed, Feb 13, 2013 at 11:57 AM, Rafael Ortiz  
> wrote:
>> Ticket created
>> http://bugs.sugarlabs.org/ticket/4428
> 
> The relevant log is Etoys.txt.

That log is about Etoys trying to read the Sugar user name. 

What does your .gconf/desktop/sugar/user/%gconf.xml look like?

OTOH, this error should happen at the startup of Etoys, not when quitting. Are 
you sure this log is produced after pressing the exit button, not before?

Also, when Etoys "hangs" after pressing the exit button (does it?), try 
pressing alt-period ("alt" + ".") which is Etoys' "user interrupt" key. That 
should also dump the stack in the log file, and would show what exactly Etoys 
is doing. Of course, you're welcome to press the "debug" button in the pink 
interrupt dialog and take a look around ;)

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fwd: Unable to exit Etoys.

[Bert Freudenberg]

On 2013-02-13, at 17:51, Rafael Ortiz  wrote:

> Hi Bert.
> 
>> 
>> On Wed, Feb 13, 2013 at 11:42 AM, Bert Freudenberg  
>> wrote:
>> 
>> On 2013-02-13, at 17:17, Rafael Ortiz  wrote:
>> 
>> >
>> > Hi
>> >
>> > We are having an error while trying to exit etoys
>> >
>> >
>> >
>> > Sugar Activity: Etoys v 113
>> >
>> > Steps to Reproduce:
>> >
>> > 1. Open Etoys activity from Home/List View
>> > 2. Perform a few operations
>> > 3. Click on 'X' button on top right of the activity menu
>> >
>> > Expected Result: Etoys Activity should exit without any errors
>> >
>> > Actual Result: Etoys Activity does not exit; neither from the activity 
>> > menu, nor from 'Stop' option from the frame.
>> > System has to be rebooted to exit from Etoys!
>> >
>> > Evidence: Screenshot and Logs attached
>> 
>> I could not read attachments. Perhaps better attach them to a bug report?
>> 
> 
> Ticket created 
> http://bugs.sugarlabs.org/ticket/4428

You attached the same bad files to the bug report.

>> In any case, if Etoys itself is still responsive, exiting should work fine, 
>> too, but it will ask first. Does clicking the (X) in the Etoys tool bar not 
>> work?
>> 
> The (X) Etoys tool bar doesn't work either. 
> 
> It ask for ''Are you sure you want to leave etoys?'' and then you click 
> ''yes''..but
> it doesn't complete the action.

That is curious indeed. Seeing the log might be helpful.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fwd: Unable to exit Etoys.

[Bert Freudenberg]

On 2013-02-13, at 17:17, Rafael Ortiz  wrote:

> 
> Hi 
> 
> We are having an error while trying to exit etoys
> 
> 
> 
> Sugar Activity: Etoys v 113
> 
> Steps to Reproduce:
> 
> 1. Open Etoys activity from Home/List View
> 2. Perform a few operations
> 3. Click on 'X' button on top right of the activity menu
> 
> Expected Result: Etoys Activity should exit without any errors
> 
> Actual Result: Etoys Activity does not exit; neither from the activity menu, 
> nor from 'Stop' option from the frame.
> System has to be rebooted to exit from Etoys!
> 
> Evidence: Screenshot and Logs attached

I could not read attachments. Perhaps better attach them to a bug report?

In any case, if Etoys itself is still responsive, exiting should work fine, 
too, but it will ask first. Does clicking the (X) in the Etoys tool bar not 
work?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Fallback to _NET_WM_PID to map windows to activities

[Bert Freudenberg]

On 2013-02-02, at 13:18, Daniel Narvaez  wrote:

> From: Daniel Narvaez 
> 
> Most toolkits supports that property, so this allows to
> write activities without setting our own custom properties,
> which is very handy if you are not using python or are not
> able to go that low level.
> 
> This is similar to what gnome-shell is doing. Simplifying
> a bit their logic to map windows to applications is
> 
> 1 Check WM_CLASS
> 2 Check _NET_WM_PID
> 3 Check startup notification properties
> 
> Now 1 is not good enough for us. They map multiple windows
> to the same application, while for us every window is a
> separate activity. About 3, we don't currently implement
> startup notification but we could in the future. In that
> case it could just be a fallback.

Sounds like a very good idea to use standard properties, yes.

> It probably make sense to keep our own custom properties
> as 1, for complicated cases like running the window in a
> subprocess.

Does anyone remember why we introduced the custom properties, instead of using 
the PID? Adding these was a hassle so there must have been a good reason.

- Bert -

> ---
> src/jarabe/model/shell.py  | 44 +---
> src/jarabe/view/service.py |  6 +++---
> 2 files changed, 28 insertions(+), 22 deletions(-)
> 
> diff --git a/src/jarabe/model/shell.py b/src/jarabe/model/shell.py
> index 437ff90..c6fe742 100644
> --- a/src/jarabe/model/shell.py
> +++ b/src/jarabe/model/shell.py
> @@ -54,7 +54,8 @@ class Activity(GObject.GObject):
> LAUNCH_FAILED = 1
> LAUNCHED = 2
> 
> -def __init__(self, activity_info, activity_id, color, window=None):
> +def __init__(self, activity_info, activity_id, bundle_id, color,
> + window=None, pid=None):
> """Initialise the HomeActivity
> 
> activity_info -- sugar3.activity.registry.ActivityInfo instance,
> @@ -74,6 +75,8 @@ class Activity(GObject.GObject):
> self._activity_info = activity_info
> self._launch_time = time.time()
> self._launch_status = Activity.LAUNCHING
> +self._bundle_id = bundle_id
> +self._pid = pid
> 
> if color is not None:
> self._color = color
> @@ -204,16 +207,13 @@ class Activity(GObject.GObject):
> return self._windows[0]
> return None
> 
> -def get_type(self):
> +def get_bundle_id(self):
> """Retrieve the activity bundle id for future reference"""
> -if not self._windows:
> -return None
> -else:
> -return SugarExt.wm_get_bundle_id(self._windows[0].get_xid())
> +self._bundle_id
> 
> def is_journal(self):
> """Returns boolean if the activity is of type JournalActivity"""
> -return self.get_type() == 'org.laptop.JournalActivity'
> +return self._bundle_id == 'org.laptop.JournalActivity'
> 
> def get_launch_time(self):
> """Return the time at which the activity was first launched
> @@ -225,9 +225,7 @@ class Activity(GObject.GObject):
> 
> def get_pid(self):
> """Returns the activity's PID"""
> -if not self._windows:
> -return None
> -return self._windows[0].get_pid()
> +return self._pid
> 
> def get_bundle_path(self):
> """Returns the activity's bundle directory"""
> @@ -530,13 +528,20 @@ class ShellModel(GObject.GObject):
> 
> activity_id = SugarExt.wm_get_activity_id(xid)
> 
> -service_name = SugarExt.wm_get_bundle_id(xid)
> -if service_name:
> +bundle_id = SugarExt.wm_get_bundle_id(xid)
> +if bundle_id:
> registry = get_registry()
> -activity_info = registry.get_bundle(service_name)
> +activity_info = registry.get_bundle(bundle_id)
> else:
> activity_info = None
> 
> +if not activity_id and window.get_pid():
> +for home_activity in self._activities:
> +launch_status = home_activity.get_launch_status()
> +if home_activity.get_pid() == window.get_pid() and \
> +launch_status == Activity.LAUNCHING:
> +activity_id = home_activity.get_activity_id()
> +
> if activity_id:
> home_activity = self.get_activity_by_id(activity_id)
> 
> @@ -551,7 +556,7 @@ class ShellModel(GObject.GObject):
> logging.debug('first window registered for %s', activity_id)
> color = self._shared_activities.get(activity_id, None)
> home_activity = Activity(activity_info, activity_id,
> - color, window)
> + bundle_id, color, window=window)
> self._add_activity(home_activity)
> else:
> logging.debug('window registered for %s', activity_id)
> @@ -626,15 +631,16 @@ class ShellModel(

Re: [Sugar-devel] Hacking onto the "appearing" and "hiding" of OSK

[Bert Freudenberg]

On 2013-01-28, at 19:16, Paul Fox  wrote:

> certainly not my call, but stealing keys which have always been
> intended for activities to use seems like it shouldn't be done
> lightly.


+1

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] How to detect touch of ebook mode?

[Bert Freudenberg]

For an activity example using multitouch see this:

http://activities.sugarlabs.org/sugar/addon/4611/

- Bert -

On 2012-12-06, at 12:17, Gonzalo Odiard  wrote:

> For a example about how to catch touch events:
> 
> http://git.sugarlabs.org/many-tests/mainline/blobs/master/touch_test.py
> 
> In this case, touch events and mouse events are managed in the same way
> 
> Gonzalo
> 
> On Thu, Dec 6, 2012 at 12:23 AM, Ariel Calzada  
> wrote:
>> Hi!
>> 
>> I'm sorry if this has been asked before but I woud like to know how to catch 
>> touch events or e-book mode programmatically?
>> 
>> Regards,
>> 
>> -- 
>> Ariel Calzada
>> Activity Central: http://www.activitycentral.com
> 
> 


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Multi-touch test activity

[Bert Freudenberg]

On 2012-11-06, at 23:50, Martin Langhoff  wrote:

> On Sun, Nov 4, 2012 at 8:29 PM, Bert Freudenberg  wrote:
>> Ah, thanks. I wasn't even going to file a bug report about the aliasing 
>> because that is a limitation inherent to the kind of sensor we have.
> 
> There are of course limitations, but we are in the process of tuning
> and tightening things on the IR.

Okay. The breaking up of touch contacts was surprising. I attached a photo here:

http://dev.laptop.org/ticket/12282

> All sensor types have some forms of aliasing. If you know how, you can
> confuse capacitive sensors too :-)

Yep. You may find my updated activity version useful in testing:

http://activities.sugarlabs.org/en-US/sugar/addon/4611/

I modified it to keep displaying the last touches.

Single-touch works pretty well already, tweaking multi-touch sounds good :)

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Multi-touch test activity

[Bert Freudenberg]

Ah, thanks. I wasn't even going to file a bug report about the aliasing because 
that is a limitation inherent to the kind of sensor we have.

Thinking about this a little bit more, only pinch/zoom will be fine. Rotation 
can still go in the wrong direction if the driver guesses the intersections 
wrongly.

- Bert -

On 2012-11-05, at 01:55, fors...@ozonline.com.au wrote:

> See also http://dev.laptop.org/ticket/12161
> 
> Tony
> 
>> Hi folks,
>> 
>> I made a simple Sugar activity to test the XO-4's multi-touch screen:
>> 
>>  http://activities.sugarlabs.org/en-US/sugar/addon/4611/
>> 
>> It works fine most of the time. Sometimes the touch contact ends 
>> unexpectedly without lifting the finger.
>> 
>> It also demonstrates that the Neonode sensor's two touch points are not 
>> independent: If you put down two fingers simultaneously, it does not know in 
>> which of the 4 possible positions the two fingers are (it only knows that 2 
>> horizontal and 2 vertical beams got obstructed) and so it has to guess. 
>> Also, the tracking sometimes "switches over", e.g. when doing a pinch-zoom 
>> using your right hand.
>> 
>> For activity developers this means that pinch/zoom and rotation gestures 
>> will work fine, but we cannot rely on truly independent touch tracking.
>> 
>> Also, two-finger sweeps are not always recognized as two fingers if they are 
>> held close together.
>> 
>> Nonetheless, it is fun to play with if you happen to have an XO-4 Touch :)
>> 
>> Source code:
>> 
>>  http://git.sugarlabs.org/testmultitouch/mainline
>> 
>> Patches welcome, but I want to keep the source simple, this is not going to 
>> become another Paint activity.
>> 
>> - Bert -
>> 
>> PS: Could some admin please delete the accidental non-mainline repo in 
>> http://git.sugarlabs.org/testmultitouch/ ? Keep "mainline", remove 
>> "testmultitouch". Thanks.
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Multi-touch test activity

[Bert Freudenberg]

Hi folks,

I made a simple Sugar activity to test the XO-4's multi-touch screen:

http://activities.sugarlabs.org/en-US/sugar/addon/4611/

It works fine most of the time. Sometimes the touch contact ends unexpectedly 
without lifting the finger.

It also demonstrates that the Neonode sensor's two touch points are not 
independent: If you put down two fingers simultaneously, it does not know in 
which of the 4 possible positions the two fingers are (it only knows that 2 
horizontal and 2 vertical beams got obstructed) and so it has to guess. Also, 
the tracking sometimes "switches over", e.g. when doing a pinch-zoom using your 
right hand.

For activity developers this means that pinch/zoom and rotation gestures will 
work fine, but we cannot rely on truly independent touch tracking.

Also, two-finger sweeps are not always recognized as two fingers if they are 
held close together.

Nonetheless, it is fun to play with if you happen to have an XO-4 Touch :)

Source code:

http://git.sugarlabs.org/testmultitouch/mainline

Patches welcome, but I want to keep the source simple, this is not going to 
become another Paint activity.

- Bert -

PS: Could some admin please delete the accidental non-mainline repo in 
http://git.sugarlabs.org/testmultitouch/ ? Keep "mainline", remove 
"testmultitouch". Thanks.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Sugar Digest 2012-09-18

[Bert Freudenberg]

On 2012-09-24, at 12:37, Bert Freudenberg  wrote:

> On 2012-09-24, at 01:40, James Cameron  wrote:
> 
>> On Sun, Sep 23, 2012 at 07:53:35PM -0300, Gonzalo Odiard wrote:
>>> Paint activity was developed by a Brazilian team and a lot of variables
>>> had Portuguese names.
>>> Whit the time, we changed a lot, but there are a few pending.
>> 
>> It is irritating that we still store source code in linear text files
>> without built-in internationalisation.
>> 
>> As you change these names, they become far less useful to programmers
>> who use that language.
>> 
>> The development system would be more open and inclusive if there was a
>> way to keep variable names, and other text, in multiple languages.
>> 
>> I've seen nothing yet that achieves this.  It would require editor
>> application support.
> 
> 
> Tile-based programming systems like Etoys, Scratch, or Turtle Art make this a 
> lot easier. They at least support switching the names of built-in functions 
> and objects.
> 
> Translating user-defined names is harder, but not impossible. I don't know of 
> any deployment-ready system, but there have been at least demos, e.g. the 
> 2004 TranSqueak project (details below, though I couldn't find a PDF online).
> 
> - Bert -


PDF of this paper on the VPRI website:

http://www.vpri.org/pdf/tr2004001_transqueak.pdf

More papers:

http://vpri.org/html/writings.php

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Sugar Digest 2012-09-18

[Bert Freudenberg]

On 2012-09-24, at 01:40, James Cameron  wrote:

> On Sun, Sep 23, 2012 at 07:53:35PM -0300, Gonzalo Odiard wrote:
>> Paint activity was developed by a Brazilian team and a lot of variables
>> had Portuguese names.
>> Whit the time, we changed a lot, but there are a few pending.
> 
> It is irritating that we still store source code in linear text files
> without built-in internationalisation.
> 
> As you change these names, they become far less useful to programmers
> who use that language.
> 
> The development system would be more open and inclusive if there was a
> way to keep variable names, and other text, in multiple languages.
> 
> I've seen nothing yet that achieves this.  It would require editor
> application support.


Tile-based programming systems like Etoys, Scratch, or Turtle Art make this a 
lot easier. They at least support switching the names of built-in functions and 
objects.

Translating user-defined names is harder, but not impossible. I don't know of 
any deployment-ready system, but there have been at least demos, e.g. the 2004 
TranSqueak project (details below, though I couldn't find a PDF online).

- Bert -

TranSqueak - making the world a smaller place: on-the-fly translation of Etoy 
projects and instant messaging

AUTHORS: Michael Rüger, Yoshiki Ohshima (Viewpoints Research Institute, 
Glendale, CA, USA)

PUBLISHED: Proceedings of Second International Conference on Creating, 
Connecting and Collaborating through Computing (C5), 2004.

ABSTRACT: This work presents an extension to the existing multilingualization 
work (ml7n) which allows people to collaborate on Squeak Etoy projects across 
different natural languages. Squeak etoys support several languages, both 
ISO-Latin based ones (erg., English, German, French), and nonISO languages 
(e.g., Japanese). Switching between languages for the Etoy tiles is fairly easy 
to support as the tiles provide a predefined set of words and phrases, which 
only need to be translated once. There are two areas where we need to go beyond 
the predefined and pretranslated set of phrases: user supplied names and 
communication between collaborators. This work presents an approach based on 
online translation services. We demonstrate a working prototype and a first 
analysis of the feasibility of this approach.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Bert Freudenberg]

On 2012-08-31, at 21:54, Gonzalo Odiard  wrote:

> * IMHO the code added to enable configure the examples directory is so 
> complicate,
> and do not add too much value. I think is better use a fixed "examples" or 
> "samples"
> (as in TurtleArt). If the maintainer want use it, should follow the 
> convention.

We are talking about pretty much just two lines:

+if cp.has_option(section, 'examples_path'):
+self._examples_path = cp.get(section, 'examples_path')

I don't see why you would consider that "too complicated". It adds value for 
activities that already have examples, when relocating them isn't that easy. 
That's a lot of bang for the buck IMHO.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] activity sandbox

[Bert Freudenberg]

On 2012-08-29, at 17:01, blekros sugar  wrote:

> Thanks, I'll check out the documentation and get up to speed a little more.  
> Meantime --
> 
> I just want to make sure I understand:
> 
> 1.   Sugar activities *are* Python scripts

... usually. Any programming language is fine for writing Sugar activities, as 
long as it can connect to D-Bus and provide an X11 user interface. But writing 
them in Python is a lot simpler because you can make use of the Sugar Toolkit 
(a Python library used by. One example of an activity not written in Python is 
Etoys.

> -- but they use Linux-specific packages, instead of using os.* or sys.* 
> packages, which wrap the OS that lies beneath.   Same for GTK+.  The GUI 
> cannot be made to use ported versions of the GTK+ API.

That's pretty much correct. At least no-one has seriously tried to make Sugar 
work elsewhere.

> 2.  The Sugar shell is not a service layer between the bare metal Linux OS 
> and Sugar presentation (its "desktop") .  In other words, the shell cannot be 
> updated to plug into to modern device OSes such as I/Pad or Android.

Well porting the shell is maybe not that hard, but that wouldn't mean the 
activities simply work, too. That's because activities are not coded purely 
against the Sugar API but may make use of stuff more generally available in 
Linux. OTOH some simple activities might just work.

> 3.  No one has attempted to port Activities, i.e. the FUN stuff,  to Browser 
> apps (HTML 5 + Javascript) so any kid with a smart phone could play with, 
> say, Physics, or Turtle.

It wouldn't be so much "porting" as reimplementing. Also you would need a 
framework for collaboration and journaling first (which is what distinguishes 
Sugar most from other environments). Individual activities aren't all that 
interesting IMHO, equivalent apps can be found for pretty much any platform. 
The way activities are assembled into a whole learning environment is Sugar's 
raison d'etre.

- Bert -

> 
> 
> Brad
> 
> 
> 
> 
> 
> 
> On Wed, Aug 29, 2012 at 7:15 AM, Bert Freudenberg  
> wrote:
> On 2012-08-28, at 15:53, Gonzalo Odiard  wrote:
> 
> > On Tue, Aug 28, 2012 at 10:49 AM, blekros sugar  
> > wrote:
> >> I'd like to use Eclipse with PyDev on Windows to try to build activities.
> >>
> >> Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a 
> >> chrome / firefox plugin so that I can use my existing environments without 
> >> VMWare or VirtualBox?
> >>
> >
> > No. Sugar run in a linux os.
> 
> Right. Sugar activities do not only require the Sugar Shell to run. They are 
> full-fledged Linux applications that follow a few additional conventions to 
> function well in Sugar. But that means that they need a full Linux + X11 
> operating system stack to work.
> 
> >> I can't find anything resembling an object model, or class diagram that 
> >> shows the architectural breakdown of Sugar.   Where to look?
> >
> > Sadly, our documentation is not in a good shape.
> > Today, the best doc is the code itself.
> 
> Well, there still is *some* documentation for activity authors.
> 
> We have a nice book:
> 
> http://en.flossmanuals.net/make-your-own-sugar-activities/
> 
> And for a more low-level understanding there is this documentation page:
> 
> http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> 
> More documentation resources are listed at
> 
> http://wiki.sugarlabs.org/go/Activity_Team/Resources
> 
> - Bert -
> 
> 
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] activity sandbox

[Bert Freudenberg]

On 2012-08-28, at 15:53, Gonzalo Odiard  wrote:

> On Tue, Aug 28, 2012 at 10:49 AM, blekros sugar  
> wrote:
>> I'd like to use Eclipse with PyDev on Windows to try to build activities.
>> 
>> Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a 
>> chrome / firefox plugin so that I can use my existing environments without 
>> VMWare or VirtualBox?
>> 
> 
> No. Sugar run in a linux os.

Right. Sugar activities do not only require the Sugar Shell to run. They are 
full-fledged Linux applications that follow a few additional conventions to 
function well in Sugar. But that means that they need a full Linux + X11 
operating system stack to work.

>> I can't find anything resembling an object model, or class diagram that 
>> shows the architectural breakdown of Sugar.   Where to look?
> 
> Sadly, our documentation is not in a good shape.
> Today, the best doc is the code itself. 

Well, there still is *some* documentation for activity authors.

We have a nice book:

http://en.flossmanuals.net/make-your-own-sugar-activities/

And for a more low-level understanding there is this documentation page:

http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API

More documentation resources are listed at

http://wiki.sugarlabs.org/go/Activity_Team/Resources

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Bert Freudenberg]

On 2012-08-22, at 04:27, Martin Abente wrote:

> Hello everyone:
> 
> From the meeting notes and Bert suggestion I have what could be called the 
> version 2 of this feature, greatly simplified and complies with everyones 
> rightful suggestions.
> 
> To avoid spaming (for some time) the sugar-devel ML I will post the patches 
> just here:
> 
> sugar: 
> http://www.sugarlabs.org/~tch/patches/examples/sugar/0001-Examples-objects-support-V2.patch
> sugar-toolkit: 
> http://www.sugarlabs.org/~tch/patches/examples/sugar-toolkit/0001-Examples_path-activity-info.patch
> 
> Feedback is welcome!
> tch

I have not tried it, but by eyeballing the code looks fine :)

- Bert -


> On Tue, Aug 21, 2012 at 3:42 PM, Martin Abente 
>  wrote:
> I don't see why not, we can achieve both things :). Maybe someone have 
> another opinion regarding this?
> 
> 
> On Tue, Aug 21, 2012 at 3:07 PM, Bert Freudenberg  
> wrote:
> On 2012-08-21, at 20:17, Martin Abente wrote:
> 
> > The design I implemented works like this:
> >
> > a. activity developers or deployments add a new "examples" folder inside 
> > the activity bundle with their examples objects.
> > b. when the activity starts, the example folder will be accessible through 
> > the journal as new volume option, and also from __any__ ObjectChooser.
> > c. Only one volume button will be shown, even when many instances of the 
> > activity are running.
> > d. The example folder will disappear from the journal when the last 
> > instance is closed.
> > [...]
> > Waiting for more feedback... :)
> 
> And in another thread:
> 
> >> instead of a magic directory name, couldn't the activity.info file have a 
> >> new entry giving the examples path?
> >
> 
> > What I tried, or I am trying, to do is to make this feature available as 
> > easy as we can, so even deployments could add their own examples with very 
> > little technical knowledge requirements. That why I try this convention 
> > (magical) idea.
> 
> 
> Okay, so by default it should look for a directory named "examples". But 
> maybe a different path could be set in activity.info?
> 
> - Bert -
> 
> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Bert Freudenberg]

On 2012-08-21, at 20:17, Martin Abente wrote:

> The design I implemented works like this:
> 
> a. activity developers or deployments add a new "examples" folder inside the 
> activity bundle with their examples objects.
> b. when the activity starts, the example folder will be accessible through 
> the journal as new volume option, and also from __any__ ObjectChooser.
> c. Only one volume button will be shown, even when many instances of the 
> activity are running.
> d. The example folder will disappear from the journal when the last instance 
> is closed.
> [...]
> Waiting for more feedback... :)

And in another thread:

>> instead of a magic directory name, couldn't the activity.info file have a 
>> new entry giving the examples path?
> 

> What I tried, or I am trying, to do is to make this feature available as easy 
> as we can, so even deployments could add their own examples with very little 
> technical knowledge requirements. That why I try this convention (magical) 
> idea.


Okay, so by default it should look for a directory named "examples". But maybe 
a different path could be set in activity.info?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Example objects support

[Bert Freudenberg]

On 2012-08-21, at 15:38, Sascha Silbe wrote:

> Martin Abente Lahaye  writes:
> 
>> +def _add_activity_example(self, home_activity):
>> +examples_path = os.path.join(home_activity.get_bundle_path(),
>> +'examples')
>> +
>> +if not os.path.exists(examples_path):
>> +return
> 
> If you add a guard against home_activity.get_bundle_path() returning
> None, you can drop the special-casing for the Journal activity.


I like the general idea very much. However, instead of a magic directory name, 
couldn't the activity.info file have a new entry giving the examples path?

This could be encapsulated in a function home_activity.get_examples_path().

The advantage of this would be that activities could specify a directory 
(relative to the bundle directory) that fits their structure better than having 
to put the examples into a fixed location in the bundle. In very special cases 
they could even give an absolute path, e.g. Etoys examples are in 
/usr/share/etoys/ExampleEtoys ...

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for a New Activity in Sugar: To code and run C, C++ programs

[Bert Freudenberg]

On 07.08.2012, at 19:17, Kartik Kumar wrote:

> C, C++ are the languages that laid foundation for OOPS(C++ to be more 
> specific).

This list here is not the place for language wars, but this statement is so far 
from the truth it cannot be left uncommented. Please learn about the history of 
computing before making such broad statements.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Engadget post on XO Touch

[Bert Freudenberg]

On 26.07.2012, at 20:21, Mike Lee wrote:

> Here's a cool demo of the Neonode multitouch frame:
> 
> http://www.slashgear.com/neonode-3d-touch-headed-to-tablets-and-phones-hands-on-28215933/
> 
> Not only multi-touch, but also entry direction and tilt. For a dollar!

Well, for tilt you would need to stack multiple frames on top of each other as 
they did in that prototype. For a touch-screen you would want it to be as thin 
as possible, that would mean single-layer. The Kindle Touch and Nook use 
Neonode zForce touch sensors, too. Here's a nice animation showing the 
principle:

http://www.neonode.com/solutions/zforce

Does anyone know how the multi-touch stuff is going to be exposed in Linux?

- Bert -


> 
> Seems like this would be great as a retrofit kit.
> 
> Mike
> 
> On Thu, Jul 26, 2012 at 11:09 PM, Sameer Verma  wrote:
> www.engadget.com/2012/07/26/olpc-xo-touch-1-75-to-use-neonode-tech/
> 
> The post says "as yet unreleased XO 1.75". What's the official status
> on the 1.75? Still as yet unreleased?
> 
> cheers,
> Sameer


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] Etoys 5.0.2408

[Bert Freudenberg]

This is a bugfix release for 5.0.

== Sources ==

http://download.sugarlabs.org/sources/sucrose/glucose/etoys/etoys-5.0.2408.tar.gz

== Changes ==

* Updated translation: bn, da, de, es, hy, nl, pt, sv, zh_CN
* Added translations: hus, en_GB
* Sugar: fix choosing objects from external media instead of Journal, and 
handle non-ASCII filenames
* make saved projects that do not use new features more likely to work in 
earlier versions of Etoys (SQ-1095)
* adds a preference, 'singlePixelNib', so the smallest brush will draw with a 
one-pixel-wide nib (SQ-1004)
* fix dropping a GIF image into Etoys (SQ-1094)
* mark month names and weekday names for translation (SQ-1102)
* some ScratchConnect fixes from Koji Yokokawa (SQ-1085, SQ-1086, SQ-1087)
* better comment in POT for translators about the meta-phrases 'Language-Name' 
and 'Language-Direction'
* Move ScratchClient to 'Tools' category
* Revert addition of graph-location watcher items to Morph's extras menu. The 
viewer is a better way to get watchers.
* minor fixes (SQ-811, SQ-869, SQ-1036, SQ-1045, SQ-1051, SQ-1088, SQ-1096, 
SQ-1099)

- Bert - (for the Etoys team)

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] sugarless.py Implode version

[Bert Freudenberg]

On 29.06.2012, at 02:00, James Cameron wrote:

> On Thu, Jun 28, 2012 at 11:36:25AM -0300, Gonzalo Odiard wrote:
>> +1 to keep the sugarless version working.
>> In the future, I hope we have more activities working in Gnome too.
> 
> I would like to see every activity as a menu option in the GNOME
> menus.  ;-}


Really?

Starting up Sugar in a window and auto-launching one of its activities would 
probably be a modestly simple change. Although it would be not as efficient as 
running Sugar on its own. (and the problem of keybindings in emulated Sugar is 
still unresolved, right?)

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Sugar as a Mac Ap?

[Bert Freudenberg]

On 2012-06-14, at 12:54, Peter Robinson wrote:

> On Wed, Jun 13, 2012 at 5:42 PM, Walter Bender  
> wrote:
>> 
>> So the question is: is there a Linux/Gnome VM for the iPad? iPhone? 
>> iWhatever?
> 
> No because Apply explicitly doesn't allow other languages so we can't
> run python which means we need some form of python -> objective-C
> compiler or similar to be able to run it on those sort of devices.

Not true. Not since 2010 anyway. You can now code iOS apps in any language you 
want. There are apps in the Apple App Store written in Squeak, and Lua, and I 
guess many other languages. E.g. here is a Python environment:

http://itunes.apple.com/us/app/python-for-ios/id485729872?mt=8

There are of course other reasons why you wouldn't get Sugar into the app store 
(see e.g. my message from yesterday). But the programming language is no 
problem.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar module build is broken by translations

[Bert Freudenberg]

On 2012-06-13, at 17:41, Simon Schampijer wrote:

> Sadly, we break rather often lately after pushes from pootle. There is no 
> verification done inside pootle itself :/
> 
> Regards,
>Simon


Maybe msgfmt errors should be treated as warnings unless you're trying to 
deployment a bundle.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Sugar as a Mac Ap?

[Bert Freudenberg]

On 2012-06-13, at 18:42, Walter Bender wrote:

> Etoys runs in a virtual machine. Once that VM is ported to a new
> environment, Etoys will run.
> Sugar on the other hand is a desktop and collection of applications
> that require Linux and the Gnome toolkit (among other dependencies).
> Once a Linux VM with Gnome is running in an environment, the process
> of porting Sugar is *relatively* painless.
> 
> So the question is: is there a Linux/Gnome VM for the iPad? iPhone? iWhatever?
> 
> -walter


Apple wouldn't allow a generic VM into their App Store. The only unrestricted 
environment on the iPad is the web browser.

I think Sugar's open and collaborative philosophy is fundamentally incompatible 
with Apple's current developer guidelines.

You could port single Sugar activities to the iPad, but since users would be 
prevented from changing them, Sugar's idea of learning by hacking would be lost.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Journal: rename object_id argument to object_id_or_path

[Bert Freudenberg]

On 2012-06-13, at 01:37, James Cameron wrote:

> Reviewed-by: James Cameron 


Thanks, James and Walter. 

I forgot to point out that there is no functional change in the patch. Just 
renaming of arguments and variables. This should not have any effects on 
calling code, unless they use keyword arguments (I did not find any occurrence, 
and it seems unlikely).

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Journal: rename object_id argument to object_id_or_path

[Bert Freudenberg]

Any comment, anyone?

This came out of the discussion that ObjectChooserResponse can not only deliver 
object IDs, but sometimes file paths, too. The argument name should reflect 
that, IMHO.

- Bert -

On 2012-06-05, at 12:47, Bert Freudenberg wrote:

> In particular, this shows up in DBus introspection. The rename should
> alert API users not to expect only an object_id.
> 
> Signed-off-by: Bert Freudenberg 
> ---
> src/jarabe/journal/journalactivity.py |   24 
> 1 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/src/jarabe/journal/journalactivity.py 
> b/src/jarabe/journal/journalactivity.py
> index bb1c7f6..bb45cf2 100644
> --- a/src/jarabe/journal/journalactivity.py
> +++ b/src/jarabe/journal/journalactivity.py
> @@ -66,19 +66,19 @@ class JournalActivityDBusService(dbus.service.Object):
> 
> @dbus.service.method(J_DBUS_INTERFACE,
> in_signature='s', out_signature='')
> -def ShowObject(self, object_id):
> -"""Pop-up journal and show object with object_id"""
> +def ShowObject(self, object_id_or_path):
> +"""Pop-up journal and show object_id_or_path"""
> 
> -logging.debug('Trying to show object %s', object_id)
> +logging.debug('Trying to show object %s', object_id_or_path)
> 
> -if self._parent.show_object(object_id):
> +if self._parent.show_object(object_id_or_path):
> self._parent.reveal()
> 
> def _chooser_response_cb(self, chooser, response_id, chooser_id):
> logging.debug('JournalActivityDBusService._chooser_response_cb')
> if response_id == gtk.RESPONSE_ACCEPT:
> -object_id = chooser.get_selected_object_id()
> -self.ObjectChooserResponse(chooser_id, object_id)
> +object_id_or_path = chooser.get_selected_object_id()
> +self.ObjectChooserResponse(chooser_id, object_id_or_path)
> else:
> self.ObjectChooserCancelled(chooser_id)
> chooser.destroy()
> @@ -99,7 +99,7 @@ class JournalActivityDBusService(dbus.service.Object):
> return chooser_id
> 
> @dbus.service.signal(J_DBUS_INTERFACE, signature='ss')
> -def ObjectChooserResponse(self, chooser_id, object_id):
> +def ObjectChooserResponse(self, chooser_id, object_id_or_path):
> pass
> 
> @dbus.service.signal(J_DBUS_INTERFACE, signature='s')
> @@ -224,8 +224,8 @@ class JournalActivity(JournalWindow):
> self.set_canvas(self._main_view)
> self._main_view.show()
> 
> -def _show_secondary_view(self, object_id):
> -metadata = model.get(object_id)
> +def _show_secondary_view(self, object_id_or_path):
> +metadata = model.get(object_id_or_path)
> try:
> self._detail_toolbox.entry_toolbar.set_metadata(metadata)
> except Exception:
> @@ -242,12 +242,12 @@ class JournalActivity(JournalWindow):
> self.set_canvas(self._secondary_view)
> self._secondary_view.show()
> 
> -def show_object(self, object_id):
> -metadata = model.get(object_id)
> +def show_object(self, object_id_or_path):
> +metadata = model.get(object_id_or_path)
> if metadata is None:
> return False
> else:
> -self._show_secondary_view(object_id)
> +self._show_secondary_view(object_id_or_path)
> return True
> 
> def __volume_changed_cb(self, volume_toolbar, mount_point):
> -- 
> 1.7.3.2
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [REMINDER] Development team meeting --- 05. June 2012 (15:00 UTC)

[Bert Freudenberg]

On 2012-06-11, at 16:16, Walter Bender wrote:

> On Mon, Jun 11, 2012 at 9:56 AM, Bert Freudenberg  
> wrote:
>> On 2012-06-11, at 15:15, Walter Bender wrote:
>>> In Amazonas last week, I had the teachers use the Duplicate feature to
>>> clone an activity (in this specific case, Labyrinth) so that they
>>> could fix a bug. They used JAMEdit to make their changes. What was
>>> missing was git, so that they could create a patch (to submit
>>> upstream) and/or create a new bundle for distribution. So +1 for
>>> adding git to the Standard Sugar build.
>> 
>> That would mean XO bundles need to ship with their git repositories. 
>> Increases the installed size by two, at least.
> 
> Not necessarily. You can just run git init to create a new repository
> on the clone, for example.

How would that help submitting proper patches?

(I'm not opposed to including git, just saying that for proper patches you need 
the proper commit history)

>> Or there would have to be a mechanism to fetch the git data (e.g. if the 
>> activity info included a repo url and commit number). That's actually how we 
>> do it in Etoys (though not using git but Monticello) - you can modify it and 
>> then diff against a version downloaded from the repository.
>> 
>> Another idea avoiding the download would be to diff the original and the 
>> copy. For that you just need a tiny shellscript (or a few lines of python).


This diffing would have the same effect as patches made from a new git 
repository.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [REMINDER] Development team meeting --- 05. June 2012 (15:00 UTC)

[Bert Freudenberg]

On 2012-06-11, at 15:15, Walter Bender wrote:
> 
> On Mon, Jun 4, 2012 at 6:10 PM, Simon Schampijer  wrote:
>> 
>> - developing Activities on the XO: maybe we should include git in the builds
>> to start with (at least on the 1.5 and 1.75)? the rpm with the deps
>> (perl-Error + perl-Git) is 3.2MB, installed 14MB, maybe it can be reduced as
>> well with making some of the deps optional? There are still people dreaming
>> of simple activity to develop and modify activities for the XO (several
>> attempts have been made here)
> 
> Slight aside
> 
> In Amazonas last week, I had the teachers use the Duplicate feature to
> clone an activity (in this specific case, Labyrinth) so that they
> could fix a bug. They used JAMEdit to make their changes. What was
> missing was git, so that they could create a patch (to submit
> upstream) and/or create a new bundle for distribution. So +1 for
> adding git to the Standard Sugar build.

That would mean XO bundles need to ship with their git repositories. Increases 
the installed size by two, at least.

Or there would have to be a mechanism to fetch the git data (e.g. if the 
activity info included a repo url and commit number). That's actually how we do 
it in Etoys (though not using git but Monticello) - you can modify it and then 
diff against a version downloaded from the repository.

Another idea avoiding the download would be to diff the original and the copy. 
For that you just need a tiny shellscript (or a few lines of python).

>> - developing Sugar on the XO: I did modify Marco's Makefile a bit to build
>> on the XO and install in the system path, have to clean that up, but that
>> work quite well at least for the toolkit and the artwork, the shell is a bit
>> more tricky if you mess it up (but there are tricks with starting sugar from
>> the xterm or in GNOME to work around that)
> 
> As per an early thread, it would be nice to be able to clone Sugar
> (perhaps using the same View Source mechanism we have for activities)
> and run the cloned version from ~/
> 
> The issue I never resolved is what to do when you have an error that
> prevents the cloned version from launching.


When launching the clone one could have a timeout after a couple seconds. E.g. 
make it write a file when it has properly started. Wait for the file to appear, 
and if it doesn't, abort the launch, and offer to try again or run the system 
version instead.

Another idea would be to have the system version detect there is a user 
version, and show a choice which one to launch. If you kill it via 
ctrl-alt-backspace (or reset or whatever), you would get back to the choice 
menu.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Bert Freudenberg]

On 2012-06-08, at 15:20, Ajay Garg wrote:
> On Fri, Jun 8, 2012 at 5:48 PM, Bert Freudenberg  wrote:
>> On 07.06.2012, at 21:36, Ajay Garg wrote:
>> 
>> > Well, we need the squeak-vm (with the "Mpeg3Plugin.c" fix) for ceibal 
>> > right-away.
>> 
>> What do you mean, "for ceibal"?
>> 
>> OLPC is working on 11.3.1, which is based on Sugar 0.94, but appears to be 
>> fairly stable. 12.x is in the works too but a bit further off. I'd have 
>> assumed that Plan Ceibal takes the latest OLPC release and customizes it. Is 
>> that not so? How does your release process work?
> 
> Well yes, that is exactly what Plan Ceibal does.
> We do the release work, as and when required by Ceibal.

So which version are you working on? 11.3.1 or 12.1.0? I am confused by you 
saying you need it "right-away", since OLPC has not released anything yet that 
you then could customize and test.

The two Etoys regressions I'm aware of in 12.1.0 is that the camera does not 
work (because the new squeak vm has not been released nor packaged) and that 
sharing doesn't work with a jabber server (because the presence service breaks 
when using gabble). There may also still be sound playing/recording issues. 

Are you tracking this work on dev.laptop.org? Or at sugarlabs? Somewhere else? 
I'm also confused by who does what, when.

>> > So, all we need to do is replace the "old" etoys.image and etoys.changes 
>> > with the "latest" etoys.image and etoys.changes, respectively?
>> > If yes, then we would be needing the SRPM for etoys-5.0.2406. (Or the 
>> > older SRPM for etoys-4.1 would do ?)
>> 
>> Err, not so fast. What I described is how you can develop stuff, and how you 
>> can test stuff that is in development.
>> 
>> You're welcome to submit fixes upstream. Here's a brief Etoys developer 
>> how-to:
>> 
>>http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt
>> 
>> Also, please subscribe to etoys-dev and tell us what you're doing:
>> 
>>http://lists.squeakland.org/mailman/listinfo/etoys-dev
>> 
> 
> Bert, I am sorry, as I wasn't clear. The detailed use-case follows ::
> 
> a)
> There is the branch etoys 5.0
> 
> b)
> However, there are still some packages, which need updating (via "update code 
> from server"). Done.
> 
> c)
> Now, all that is needed to be done, is to package etoys in such a way, that 
> etoys-image (when next launched), does not re-need "update code from server".
> Of course, any local changes (that have been not been pushed upstream), don't 
> take effect. The important thing is that, the upstreamed changes should be 
> the latest one. No "update code from server" should be needed again.
> 
> I was asking about this use-case. In this, would the simple replacements of 
> etoys.image, and etoys.contents work?

It might work, but I'd rather follow proper procedure. We are planning a bugfix 
release for Etoys, just like Sugar had bug fix releases for 0.96.

Also, I was under the impression that you were looking into the MP3 rewind 
problem. If you have a fix for that you should submit it upstream. Or at least 
open a ticket at

http://tracker.squeakland.org/

>> PS: it would be nice if you could disable the HTML mails in your client. 
>> Makes proper quoting hard.

Still HTML.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Bert Freudenberg]

On 07.06.2012, at 21:36, Ajay Garg wrote:

> Thanks Bert for the reply.
> 
> On Thu, Jun 7, 2012 at 8:27 PM, Bert Freudenberg  wrote:
>> On 07.06.2012, at 15:57, Ajay Garg wrote:
>> 
>> > Hi Bert.
>> >
>> > a)
>> > Could you give a rough idea, as to what is the release cycle for squeak-vm?
>> 
>> There is no fixed release cycle, releases are done as needed and as time 
>> permits. Once or twice a year has been typical.
>> 
>> What is your time frame? If need be one could package a Squeak VM + patches.
> 
> Well, we need the squeak-vm (with the "Mpeg3Plugin.c" fix) for ceibal 
> right-away.

What do you mean, "for ceibal"?

OLPC is working on 11.3.1, which is based on Sugar 0.94, but appears to be 
fairly stable. 12.x is in the works too but a bit further off. I'd have assumed 
that Plan Ceibal takes the latest OLPC release and customizes it. Is that not 
so? How does your release process work? 

> It will be best, if you could provide with any of the following options  ::
> 
> a)
> "squeak-vm-4.4.47 RPM for x86 "AND "squeak-vm-4.4.47 RPM for ARM".
> 
>OR
> b)
> "squeak-vm-4.4.47 SRPM".

I can't provide any of that. My spare time is limited, you know ;)

(I am a freelancing developer, but my schedule is pretty full. I take on the 
occasional contract, in particular if 

> So, all we need to do is replace the "old" etoys.image and etoys.changes with 
> the "latest" etoys.image and etoys.changes, respectively?
> If yes, then we would be needing the SRPM for etoys-5.0.2406. (Or the older 
> SRPM for etoys-4.1 would do ?)

Err, not so fast. What I described is how you can develop stuff, and how you 
can test stuff that is in development.

You're welcome to submit fixes upstream. Here's a brief Etoys developer how-to:

http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt

Also, please subscribe to etoys-dev and tell us what you're doing:

http://lists.squeakland.org/mailman/listinfo/etoys-dev

- Bert -

PS: it would be nice if you could disable the HTML mails in your client. Makes 
proper quoting hard.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 06.06.2012, at 20:19, Ajay Garg  wrote:

> When a file was checked out from the datastore, an activity needs to delete 
> it when it is done. Etoys deletes the file when the file object is released 
> (using a finalizer). I guess the MPEGPlayer stores only the name, closes the 
> file, and tries to re-open it from the same name. If the original file object 
> has been garbage-collected already, the finalizer will have deleted the file. 
> Thus, trying to re-open it will fail.
> 
> 
> I guess this is what is happening.
> 
> 
> Some thoughts ::
> 
> a)
> So, the reason that things work fine in the case of USB drives, is because 
> there is always a reference to the file by the OS. Thus, the file itself is 
> never deleted.

Yes.


> b)
> More importantly, WHY WOULD MPEGPLAYER NEED TO DELETE THE FILE? CAN THE FILE 
> SIMPLY NOT BE ACCESSED IN A UNIFORM MANNER FROM BOTH JOURNAL AND USB PEN 
> DRIVES?
> As part of this, I tried using the journal file simply (without making its 
> copy). So, now "Rewind" worked. But the next time, "Rewind" did not work, 
> apparently because the file was deleted.
> 
> 
> So,
> WHY WOULD MPEGPLAYER NEED TO DELETE THE FILE? CAN THE FILE SIMPLY NOT BE 
> ACCESSED IN A UNIFORM MANNER FROM BOTH JOURNAL AND USB PEN DRIVES, WITHOUT 
> HAVING THE NEED TO DELETE THE FILE ALTOGETHER?
> 

Because that is how the Sugar datastore works:

http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Keeping_and_Resuming

When you call get_filename() on the datastore object, a copy is made by the 
datastore, which the activity needs to delete.

And it's not the MPEG player which deletes the file, but SugarLauncher.

> On an unrelated note :: Thanks a ton for the tutorials on  squeak. I could 
> finally do some live debugging :D :D
> Thanks again.
> 
> Thanks and Regards,
> Ajay

Hehe. Be careful, you may like what you learn ;)

(in that case, you should maybe get someone to send you to the Smalltalks 
conference in Argentina in November)

- Bert -___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Bert Freudenberg]

On 07.06.2012, at 15:57, Ajay Garg wrote:

> Hi Bert.
> 
> a)
> Could you give a rough idea, as to what is the release cycle for squeak-vm?

There is no fixed release cycle, releases are done as needed and as time 
permits. Once or twice a year has been typical.

What is your time frame? If need be one could package a Squeak VM + patches.

> b)
> Also, I installed etoys-5.0.2406 rpm; and did (as told by you) "update code 
> from server".
> However, upon reboot, I again have to do "update code from server".

No need to reboot, quitting Etoys is enough. Any changes made are not 
permanent, to encourage free experimentation without breaking anything. 
Normally Etoys only stores projects (which can contain code), the image is 
read-only.

> So, is there a way that a "final" etoys image (incorporating all the latest 
> changes) can be retrieved (locally)? That is, we may do all the updating from 
> "update code from server", and then transfer the "final" etoys.image at will?

Of course there is a way ;)

First, copy some files from /usr/share/etoys over to Etoys' 
$SUGAR_ACTIVITY_ROOT/data direcory:

[olpc@xo-a7-4a-a4 ~]$ cd .sugar/default/org.vpri.EtoysActivity/data
[olpc@xo-a7-4a-a4 data]$ cp /usr/share/etoys/etoys.{image,changes} .
[olpc@xo-a7-4a-a4 data]$ ln -s 
/usr/share/etoys/{locale,ExampleEtoys,EtoysV5.stc} .
[olpc@xo-a7-4a-a4 data]$ ll
insgesamt 17424
-rw-r--r-- 1 olpc olpc 5014  7. Jun 14:34 etoys.changes
-rw-r--r-- 1 olpc olpc 17823140  7. Jun 14:34 etoys.image
lrwxrwxrwx 1 olpc olpc   28  7. Jun 14:34 EtoysV5.stc -> 
/usr/share/etoys/EtoysV5.stc
lrwxrwxrwx 1 olpc olpc   29  7. Jun 14:34 ExampleEtoys -> 
/usr/share/etoys/ExampleEtoys
lrwxrwxrwx 1 olpc olpc   23  7. Jun 14:34 locale -> /usr/share/etoys/locale
drwxrwxr-x 3 olpc olpc 4096  7. Jun 14:20 MyEtoys
drwxrwx--- 3 olpc olpc 4096 31. Mai 17:53 private

(you could also make the files in /usr/etoys/share writable, but copying is 
safer)
(if your XO uses Rainbow security, the Etoys $SUGAR_ACTIVITY_ROOT will be 
somewhere in the isolation directory instead)

The next time you launch Etoys, it will use this image at 
$SUGAR_ACTIVITY_ROOT/data/etoys.image instead. (Etoys also looks for a 
developer image on a USB stick, see Etoys.activity/bin/etoys-activity and use 
whatever is most convenient)

Now you are ready for serious Squeak development.

1) The secret is Alt-Shift-W. Press this to bring up the full Squeak world menu.
2) From the menu, choose "previous project". This will jump to a hidden unnamed 
project. You should recolor this project to remind you this is not the default 
Etoys anymore (right-click, use the lower-right halo handle to choose a 
different background color)
3) Load updates
4) Press Alt-Shift-W again, choose "save and quit". Do not use "save as" or 
"save new version" because those would create new file names.

Done. The next time you launch Etoys, you will see it using your image (because 
of the different background color). Always go back to the top-level project 
before saving. Of course, this will also retain all changes you make, windows 
you have open etc. Make yourself a nice dev environment :)

(there is an older version of these instructions, plus a nice tutorial, at 
http://wiki.laptop.org/go/Smalltalk_Development_on_XO )

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 07.06.2012, at 12:54, Manuel Kaufmann wrote:

> On Wed, Jun 6, 2012 at 12:46 PM, Bert Freudenberg  
> wrote:
>> Both Etoys 4 and Etoys 5 work fine with the presence service in Sugar 0.94 
>> (tested on XO-1.5, 11.3.1 build 885).
> 
> I'm not sure to understand this comment. Are you saying that Etoys 5
> works fine but it can not be shared or "works fine" means that you can
> run it and play with Etoys but alone?

I'm saying that sharing works. Both in Etoys 4 and Etoys 5. But only if the 
presence service works.

If the presence service does not work, sharing does not work in Etoys.

With regard to sharing, the only difference between Etoys 4 and Etoys 5 is that 
Etoys 5 will still work if the presence service fails, whereas Etoys 4 showed 
an error on startup.

>> I am re-implementing the presence service in Etoys, but this is going to 
>> take a while longer. If you want sharing to work with Etoys right now, the 
>> easiest would be to fix the presence service (which is a Python task, so may 
>> be easier for you).
> 
> Maybe I can help with this but I have no idea about "presence
> service", I should study about it. Is there a ticket with this issue
> with a bit of history that I can read to catch up?

Hmm, the history goes back a couple of years. There probably is a ticket, and a 
mailing list discussion. Here is the removal feature page:

http://wiki.sugarlabs.org/go/Features/Remove_Presence_Service

This ticket describes the current problem:

http://bugs.sugarlabs.org/ticket/3498

The presence service crashes when it is trying to use gabble (that is, a jabber 
server). It appears to work fine with salut (that is, in the local network 
without a server).

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 06.06.2012, at 16:00, Ajay Garg wrote:

> Hi Bert.
> 
> Is there a way to do a textual search for a text across the entire code?
> For example, I am trying to search for the string "Rewind" across the code, 
> but cannot find a single occurrence (via Ctrl-f and Ctrl-g).

Yes, ctrl-shift-E.

There is a command key list in the help menu. 

Also, there is a Squeak-beginners mailing list:

http://lists.squeak.org/mailman/listinfo/beginners

And some documentation links on the Squeak website:

http://squeak.org/Documentation/

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 06.06.2012, at 14:44, Manuel Kaufmann wrote:

> On Mon, May 28, 2012 at 1:49 PM, Bert Freudenberg  
> wrote:
>> Again, Etoys 5 starts fine, Etoys 4.1 not. But we cannot really test distro 
>> stuff if it has not been packaged yet.
> 
> I found Etoys 5 already compiled here[1], I download it and tested on
> XO 1.5 os12. Here is my report:
> 
> I could start it without any problem, everything was OK, I could play
> and test some Example Project but when I tried to "Share" the activity
> clicking on the "Share button" and then on "My Neighbourhood" I get
> this error:
> 
> * Screenshot: 
> http://mkaufmann.com.ar/~humitos/olpc/Captura%20pantalla%20de%20_Etoys_%20Gallery_.png
> * Log: http://fpaste.org/oAPi/


This is expected, kind-of anyway. If the presence service was still working 
correctly, then we would not have had the startup error in the first place. 
Etoys 5 just ignores the presence service errors on startup, so you can use it 
locally, at least. Etoys 4 showed the error right away, which in a way is 
better since it alerted people that the presence service was broken. (The 
presence service has been deprecated for a long time, so I couldn't complain 
about it being broken)

Both Etoys 4 and Etoys 5 work fine with the presence service in Sugar 0.94 
(tested on XO-1.5, 11.3.1 build 885).

I am re-implementing the presence service in Etoys, but this is going to take a 
while longer. If you want sharing to work with Etoys right now, the easiest 
would be to fix the presence service (which is a Python task, so may be easier 
for you).

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 22:53, Ajay Garg wrote:

> Hi Bert.
> 
> There is good news, and (rather mild bad news).
> 
> 
> I updated the code from etoys4.1 to etoys5.0, as suggested by you via "update 
> code from server", and the following use-cases worked perfectly as expected ::
> 
> 
> a)
> Open an mp3 from a USB pen-drive via journal-object-chooser.
> Click "Play in MPEG player".
> The mp3 starts playing.
> Click "Stop".
> Click "Play".
> mp3 resumes playing.
> Click "Stop".
> Click "Rewind".
> Click "Play".
> mp3 starts playing from the beginning.
> 
> 
> b)
> Open an mp3 from a USB pen-drive via journal-object-chooser.
> Click "Open".
> Click "Play".
> The mp3 starts playing.
> Click "Stop".
> Click "Play".
> mp3 resumes playing.
> Click "Stop".
> Click "Rewind".
> Click "Play".
> mp3 starts playing from the beginning.
> 
> 
> c)
> Open an mp3 from the journal via journal-object-chooser.
> Click "Play in MPEG player".
> The mp3 starts playing.
> Click "Stop".
> Click "Play".
> mp3 resumes playing.
> Click "Stop".
> Click "Rewind".
> Click "Play".
> mp3 DOES NOT PLAY. Instead an error comes up, saying that the file-name has 
> changed.
> 
> 
> d)
> Open an mp3 from the journal via journal-object-chooser.
> Click "Open".
> Click "Play".
> The mp3 starts playing.
> Click "Stop".
> Click "Play".
> mp3 resumes playing.
> Click "Stop".
> Click "Rewind".
> Click "Play".
> mp3 DOES NOT PLAY. Instead an error comes up, saying that the file-name has 
> changed.
> 
> 
> e)
> I tried steps a), b), c), d) with etoys4.1.
> a) and b) failed (for obvious reasons).
> c) and d) ALSO failed, with the same symptoms.

So it plays once and but not again. I have a hunch.

When a file was checked out from the datastore, an activity needs to delete it 
when it is done. Etoys deletes the file when the file object is released (using 
a finalizer). I guess the MPEGPlayer stores only the name, closes the file, and 
tries to re-open it from the same name. If the original file object has been 
garbage-collected already, the finalizer will have deleted the file. Thus, 
trying to re-open it will fail.

> f)
> I tried installing the new rolled out etoys-5.0.2406-1.fc17.noarch.rpm
> However, it needed a squeak-vm greater than 3.10.
> Now, I had uninstalled the squeak-vm, and installed it instead via source 
> (for 4.0 branch).
> So, I installed the rpm by "sudo rpm -i --nodeps 
> etoys-5.0.2406-1.fc17.noarch.rpm".
> a) and b) CONTINUED TO FAIL (meaning that the change did not take effect).

It's not yet in 5.0.2406. You need to "update code from server".

> So, Bert,
> 
> (i)
> Could the new rpm for squeak-vm (from 4.0 branch) also be rolled out; so that 
> the mpeg-plugin change could also be tested end-to-end.

It would be a good idea to package the current 4.4.7 Squeak VM in any case. But 
it does not have my latest patches yet. I've sent the patches two weeks ago, 
but there was no new release yet.

> (ii)
> Kindly provide me a snapshot of your last commit, so that I may go through 
> the mechanics of making the change in etoys. I would then subequently like to 
> fix cases c) and d)  :-)

I'm not quite sure what you mean with "snapshot of your last commit"?

Fixing the c) and d) cases is not exactly a task I would give to a new Squeak 
programmer. You're welcome to surprise me, of course ;) You would have to start 
at SugarLauncher's "getFile:" method.

- Bert -

> 
> Thanks a ton 
> 
> 
> Thanks and Regards,
> Ajay
> 
> 
> 
> 
> 
> On Tue, Jun 5, 2012 at 10:26 PM, Bert Freudenberg  
> wrote:
> 
> On 05.06.2012, at 15:57, Bert Freudenberg wrote:
> 
> > On 05.06.2012, at 15:33, Ajay Garg wrote:
> >
> >> Bert,
> >>
> >> A small query ::
> >>
> >> I have the version "etoys4.1".
> >> Is the "5.0.2406" version based on a higher release version of Fedora?
> >
> > Fedora is a Linux distribution. Etoys is an application. Your question 
> > makes no sense to me.
> >
> > Or are you asking if Etoys 5 requires Fedora 17? No, it does not. Etoys is 
> > cross-platform and hopefully works everywhere. See
> >
> >   http://squeakland.org/download/
> >
> > And poke around on that site to see what makes Etoys special (and not just 
> > weird). In particular, read 

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 15:57, Bert Freudenberg wrote:

> On 05.06.2012, at 15:33, Ajay Garg wrote:
> 
>> Bert, 
>> 
>> A small query ::
>> 
>> I have the version "etoys4.1".
>> Is the "5.0.2406" version based on a higher release version of Fedora?
> 
> Fedora is a Linux distribution. Etoys is an application. Your question makes 
> no sense to me.
> 
> Or are you asking if Etoys 5 requires Fedora 17? No, it does not. Etoys is 
> cross-platform and hopefully works everywhere. See
> 
>   http://squeakland.org/download/
> 
> And poke around on that site to see what makes Etoys special (and not just 
> weird). In particular, read the articles at
> 
>   http://squeakland.org/resources/articles/
> 
> For testing purposes I build my own rpms (including etoys 5):
> 
>   http://etoys.laptop.org/
> 
> Or you might install from the source tar balls at
> 
>   http://download.sugarlabs.org/sources/sucrose/glucose/etoys/
> 
> [You can actually update from etoys 4.1 but that's not officially supported. 
> It will take a lot longer, and you will not get the new supporting files like 
> translations etc. You need to say "yes" when asked to advance to etoys 5, 
> "no" when asked to load newest packages. Then update again, this time you can 
> say "yes" to the newest packages.]
> 
> - Bert -

Oh, and news from the dev meeting: Peter packaged Etoys 5 for Fedora. If you 
give it karma after testing, it should become an update soonish:

https://admin.fedoraproject.org/updates/etoys-5.0.2406-1.fc17

Direct RPM link:

http://kojipkgs.fedoraproject.org/packages/etoys/5.0.2406/1.fc17/noarch/etoys-5.0.2406-1.fc17.noarch.rpm


- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 05.06.2012, at 16:39, Simon Schampijer wrote:

> On 06/01/2012 05:24 PM, Bert Freudenberg wrote:
>> On 28.05.2012, at 21:48, Bert Freudenberg wrote:
>> 
>>> On 28.05.2012, at 20:29, Peter Robinson wrote:
>>> 
>>>> As mentioned previously look at the other Activities, like TurtleArt,
>>>> it works like the rest of the distro translation stuff, I'm not sure
>>>> if there's other sugar bits that assist with that.
>>> 
>>> Other activities have only a single mo file. Other activities use the 
>>> gettext library so they do not have to worry about where the files are.
>>> 
>>> Etoys has multiple mo files. Etoys does not use gettext, so it needs to 
>>> know where to find the translation files.
>> 
>> I would add that other activities only have translated LC_MESSAGES. Etoys 
>> also has translated QuickGuides, see its current locale directory.
>> 
>>> It's precisely about those differences I'm asking you for clarification. 
>>> See my previous message.
>>> 
>>> Until now, Etoys just did its own thing, and that worked fine. But there 
>>> must be a good reason why you want the mo files in the system default 
>>> directory. (What is that reason, btw?) So I'm trying to find a way to make 
>>> it happen. If I know what the constraints are, we surely can find a way to 
>>> make it fit.
>>> 
>>> - Bert -
>> 
>> 
>> So, what are the constraints?
>> 
>> - Bert -
> 
> Hi Bert,
> 
> so looks like the main issue about translations is installing the .mo files 
> on a non standard place in a non standard way.
> 
> A few questions around the topic:
> 
> - can the mo files be in one file?

Due to the high number of translatable phrases, translators prefer separate PO 
files. Squeak + Etoys has more strings than the rest of Sugar combined. 

We could merge all MO files in the build process (and this would have some 
other advantages, so I like it), but it would be another "specialty" of Etoys 
where PO names to not match the MO.

> - if not, can they be renamed with a prefix like you suggested?

I see no technical reason why that should not work. It will require code 
changes, but they should be minor. And it will require coordination with Pootle 
- I could easily change the file names in SVN, but Pootle may get confused.

> - as far as I understood you don't use gettext, I presume that is out of 
> question, right?

Someone would need to write a Squeak VM plugin wrapping gettext. Not out of the 
question, but unlikely.

However, any of the above only concerns MO files. As I asked previously:

In addition to the gettext files, Etoys also has translated QuickGuides (and 
may later have translated example projects etc). See its current locale 
directory, e.g.

http://etoys.squeak.org/svn/trunk/Etoys/locale/de/

Since these files are quite large, it would totally make sense to e.g. include 
them in language packs. But should they be in /usr/share/locale? If not, then 
why can't the rest of the Etoys locale files stay in /usr/share/etoys/locale?

> I am sure we can sort this out in one way or another to make Peter's life 
> easier.

I certainly hope so!

> Thanks,
>   Simon
> 
> PS: I am sending you good energy to finally do the move handle presence 
> inside Etoys, so we can kill the PS. I know you are on your own in Etoys land 
> atm...but you are skilled :)

Oh I feel the wave of energy coming ... :)

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] 0.96 Change?

[Bert Freudenberg]

On 05.06.2012, at 10:04, Sascha Silbe wrote:

> Art Hunkins  writes:
> 
>> I notice that for Sugar 0.96 it seems necessary, in copying a file from the 
>> Terminal to a USB stick, to do:
>>  cp myfile.py /run/media/liveuser/myUSB/myfile.py (perhaps I've got 
>> liveuser and myUSB reversed)
>> instead of the much simpler (in 0.94 and before):
>>  cp myfile.py /media/myUSB/myfile.py
>> (two new levels!)
> 
> That's a change on the distro level (Fedora resp. systemd in this case),
> not in Sugar. When running Sugar 0.96 on most other distros (that don't
> use systemd), it will still be /media/. When running Sugar
> 0.94 (or really any version of Sugar) on Fedora 17, it will also be
> /run/media//. You can't derive the path to use
> From the Sugar version. For use in Activities, let me quote a recent
> mail of mine:
> 
>>> They should use proper API (gio on recent distros, HAL on old OLPC OS
>>> builds) rather than hardcoding paths. Check out the gio VolumeMonitor
>>> API documentation [1] and see _find_media() [2] in Backup [3] for an
>>> example (including fallback to HAL).
> 
> 
> [1] http://developer.gnome.org/gio/stable/GVolumeMonitor.html
> [2] https://git.sugarlabs.org/backup/mainline/blobs/master/backup.py#line671
> [3] http://activities.sugarlabs.org/en-US/sugar/addon/4326

I put that info into the documentation at

http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#External_Media

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 15:33, Ajay Garg wrote:

> Bert, 
> 
> A small query ::
> 
> I have the version "etoys4.1".
> Is the "5.0.2406" version based on a higher release version of Fedora?

Fedora is a Linux distribution. Etoys is an application. Your question makes no 
sense to me.

Or are you asking if Etoys 5 requires Fedora 17? No, it does not. Etoys is 
cross-platform and hopefully works everywhere. See

http://squeakland.org/download/

And poke around on that site to see what makes Etoys special (and not just 
weird). In particular, read the articles at

http://squeakland.org/resources/articles/

For testing purposes I build my own rpms (including etoys 5):

http://etoys.laptop.org/

Or you might install from the source tar balls at

http://download.sugarlabs.org/sources/sucrose/glucose/etoys/

[You can actually update from etoys 4.1 but that's not officially supported. It 
will take a lot longer, and you will not get the new supporting files like 
translations etc. You need to say "yes" when asked to advance to etoys 5, "no" 
when asked to load newest packages. Then update again, this time you can say 
"yes" to the newest packages.]

- Bert -

> Regards,
> Ajay
> 
> 
> On Tue, Jun 5, 2012 at 1:45 PM, Bert Freudenberg  wrote:
> On 05.06.2012, at 07:31, Ajay Garg wrote:
> 
> > Also, is there a 'development-branch" for etoys :-P , from where etoys 
> > binary can be downloaded, and tested ?
> 
> We only build new images in the "hot" development phase before a new release.
> 
> In between, you can test by loading updates from inside Etoys:
> 
> * make sure you use the latest release image (Etoys 5.0.2406)
> * to check version, choose "help" - "about this system" from the view source 
> menu (ctrl-comma)
> * to update, choose "help" - "update code from server" from the same menu, 
> answer "yes" to load the latest packages
> 
> After updating, the system version will include a repository version and 
> date. After my fix it's v1637 and 4 June 2012.
> 
> - Bert -
> 
> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH sugar] Journal: rename object_id argument to object_id_or_path

[Bert Freudenberg]

In particular, this shows up in DBus introspection. The rename should
alert API users not to expect only an object_id.

Signed-off-by: Bert Freudenberg 
---
 src/jarabe/journal/journalactivity.py |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/jarabe/journal/journalactivity.py 
b/src/jarabe/journal/journalactivity.py
index bb1c7f6..bb45cf2 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -66,19 +66,19 @@ class JournalActivityDBusService(dbus.service.Object):
 
 @dbus.service.method(J_DBUS_INTERFACE,
 in_signature='s', out_signature='')
-def ShowObject(self, object_id):
-"""Pop-up journal and show object with object_id"""
+def ShowObject(self, object_id_or_path):
+"""Pop-up journal and show object_id_or_path"""
 
-logging.debug('Trying to show object %s', object_id)
+logging.debug('Trying to show object %s', object_id_or_path)
 
-if self._parent.show_object(object_id):
+if self._parent.show_object(object_id_or_path):
 self._parent.reveal()
 
 def _chooser_response_cb(self, chooser, response_id, chooser_id):
 logging.debug('JournalActivityDBusService._chooser_response_cb')
 if response_id == gtk.RESPONSE_ACCEPT:
-object_id = chooser.get_selected_object_id()
-self.ObjectChooserResponse(chooser_id, object_id)
+object_id_or_path = chooser.get_selected_object_id()
+self.ObjectChooserResponse(chooser_id, object_id_or_path)
 else:
 self.ObjectChooserCancelled(chooser_id)
 chooser.destroy()
@@ -99,7 +99,7 @@ class JournalActivityDBusService(dbus.service.Object):
 return chooser_id
 
 @dbus.service.signal(J_DBUS_INTERFACE, signature='ss')
-def ObjectChooserResponse(self, chooser_id, object_id):
+def ObjectChooserResponse(self, chooser_id, object_id_or_path):
 pass
 
 @dbus.service.signal(J_DBUS_INTERFACE, signature='s')
@@ -224,8 +224,8 @@ class JournalActivity(JournalWindow):
 self.set_canvas(self._main_view)
 self._main_view.show()
 
-def _show_secondary_view(self, object_id):
-metadata = model.get(object_id)
+def _show_secondary_view(self, object_id_or_path):
+metadata = model.get(object_id_or_path)
 try:
 self._detail_toolbox.entry_toolbar.set_metadata(metadata)
 except Exception:
@@ -242,12 +242,12 @@ class JournalActivity(JournalWindow):
 self.set_canvas(self._secondary_view)
 self._secondary_view.show()
 
-def show_object(self, object_id):
-metadata = model.get(object_id)
+def show_object(self, object_id_or_path):
+metadata = model.get(object_id_or_path)
 if metadata is None:
 return False
 else:
-self._show_secondary_view(object_id)
+self._show_secondary_view(object_id_or_path)
 return True
 
 def __volume_changed_cb(self, volume_toolbar, mount_point):
-- 
1.7.3.2

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser

[Bert Freudenberg]

On 05.06.2012, at 09:21, Sascha Silbe wrote:

> Bert Freudenberg  writes:
> 
>> On 04.06.2012, at 14:13, Bert Freudenberg wrote:
>> 
>>> So you're saying that in the response, the second argument would more
>>> properly be named object_id_or_full_path. And to distinguish the two
>>> cases, we have to look at its first character: if it is '/' then it's
>>> a path, otherwise an object id. 
> 
> Yes, exactly.
> 
> 
>> I now extended that documentation page with the object_id_or_full_path
>> argument discussion.
> 
> Thanks! Just one minor point (re. "this is a utf8-encoded absolute path
> to a file"): Unix paths are sequences of octets (binary strings), not
> character strings. In most cases the path will be the representation of
> a character string in some encoding (and Sugar only works with the UTF-8
> encoding). But it's never the other way around (the path itself getting
> UTF-8 encoded). However, you do have a point in that paths that are not
> a valid UTF-8 representation of some character string will cause the
> Object Chooser to break.

You're right. I removed the encoding part from the API doc.

>>> Are there any other places in the API where instead of an object id we have 
>>> to expect a full path instead?
> 
> I would expect only the Journal D-Bus API to work this way. So
> org.laptop.Journal.ShowObject() should be the only other place where
> object_id or a full path is used (resp. supported).


Okay. I checked, ShowObject() indeed supports a full path. Which can be 
anywhere on the system, actually. Opening a file from there copies it to the 
Journal.

I will send a patch to rename object_id. That should alert future users that 
object_id might also be a path.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Fwd: Scratch source code version 1.4.0.6 released

[Bert Freudenberg]

Begin forwarded message:

> From: Amos Blanton 
> Subject: Scratch source code version 1.4.0.6 released
> Date: 5. Juni 2012 03:23:50 MESZ
> To: Linux Scratch , scra...@lists.launchpad.net, 
> Debian Bugs <471...@bugs.debian.org>
> 
> We've released an update to the GPL v2 Scratch source code ,  now available 
> here:
> 
> http://download.scratch.mit.edu/scratch-1.4.0.6.src.tar.gz
> 
> 1.4.0.6 changes:
> * Fix for "blank screen" bug when image is run on current Squeak VMs (Thanks 
> to Bert Freudenberg for the fix.) 
> * Squeak source code for version of Scratch 1.4 modified for XO / Sugar
> 
> Scratch On!
> Amos
> Scratch Team


This now could be used to make a GPL Scratch activity.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 07:31, Ajay Garg wrote:

> Also, is there a 'development-branch" for etoys :-P , from where etoys binary 
> can be downloaded, and tested ?

We only build new images in the "hot" development phase before a new release.

In between, you can test by loading updates from inside Etoys:

* make sure you use the latest release image (Etoys 5.0.2406)
* to check version, choose "help" - "about this system" from the view source 
menu (ctrl-comma)
* to update, choose "help" - "update code from server" from the same menu, 
answer "yes" to load the latest packages

After updating, the system version will include a repository version and date. 
After my fix it's v1637 and 4 June 2012.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 07:25, Ajay Garg wrote:

> 
> Just wish to confirm, if the following hold true ::
> 
> a)
> As mentioned in one of the earlier emails, 'get_properties' method needs to 
> succeed to open a journal/external-USB-drive object.
> So, my query is : is the end-result just opening of the file (from 
> journal/external-USB-drive), or something more too ?

The Etoys code just assumed that object_id was in fact an UID for the 
datastore. To get the file associated with a UID you need to call 
get_properties. However, what we get from the object chooser is not always a 
UID, but sometimes a full path. We must not call get_properties on that, but 
simply open it.

> b)
> If the answer to a) is "just opening the file", then I presume your commit 
> fixes/enhances the case of opening the file from external-USB-drive ?

Yes, my fix to Etoys means that it can now use the object chooser to open files 
from external USB drive.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 04.06.2012, at 14:13, Bert Freudenberg wrote:

> On 04.06.2012, at 13:43, Sascha Silbe wrote:
> 
>> It's quite likely that Etoys doesn't implement its side of the
>> essentially undocumented Object Chooser API of Sugar 0.84+ correctly. In
>> particular, the object_id parameter of the ObjectChooserResponse signal
>> will contain a) the data store object id (currently stored as property
>> 'uid') for Journal objects or b) the full path to the file for entries
>> stored on external storage media.
> 
> That is indeed the first time I hear of that. Yes, Etoys expects the 
> chooser's response to be an object_id as per documentation at
> 
>   
> http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Choosing_Objects
> 
> So you're saying that in the response, the second argument would more 
> properly be named object_id_or_full_path. And to distinguish the two cases, 
> we have to look at its first character: if it is '/' then it's a path, 
> otherwise an object id. 

I now extended that documentation page with the object_id_or_full_path argument 
discussion.

Also, I committed a fix for Etoys, will be in the next release.

This question remains:

> Are there any other places in the API where instead of an object id we have 
> to expect a full path instead?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] SUGAR_LANGPACKDIR

[Bert Freudenberg]

On 04.06.2012, at 19:15, Simon Schampijer wrote:

> On 06/04/2012 07:04 PM, Bert Freudenberg wrote:
>> On 04.06.2012, at 18:51, Simon Schampijer wrote:
>> 
>>> +langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
>>> +if langpackdir is not None and langpackdir:
>>> +os.environ['SUGAR_LANGPACKDIR'] = langpackdir
>> 
>> How should activities use SUGAR_LANGPACKDIR? Google comes up empty.
>> 
>> - Bert -
> 
> This is only a workaround for a bug:
> 
> http://bugs.sugarlabs.org/ticket/3654
> 
> http://lists.sugarlabs.org/archive/sugar-devel/2012-May/037678.html
> 
> The initial idea is described at, it is a gconf variable:
> http://wiki.sugarlabs.org/go/Features/Enhanced_Gettext
> 
> Regards,
>   Simon

Well, env vars are much easier to deal with than gconf. Is this something an 
activity can rely on now?

How about SUGAR_LOCALEDIR? Is that always ${SUGAR_BUNDLE_PATH}/locale ?

Reading the code, the procedure seems to be to pick the latest MO file found in 
any of these directories

${SUGAR_LOCALEDIR}  (from ${SUGAR_BUNDLE_PATH}/locale )
${SUGAR_LANGPACKDIR}(from gconf 
/desktop/sugar/i18n/langpackdir )
${prefix}/share/locale  (where prefix is compiled into the 
bundle, typically /usr or /usr/local)

and where "latest MO" means opening all MO files and comparing their 
‘PO-Revision-Date:’ header.

Is that interpretation correct? And complete?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] SUGAR_LANGPACKDIR

[Bert Freudenberg]

On 04.06.2012, at 18:51, Simon Schampijer wrote:

> +langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
> +if langpackdir is not None and langpackdir:
> +os.environ['SUGAR_LANGPACKDIR'] = langpackdir

How should activities use SUGAR_LANGPACKDIR? Google comes up empty.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 04.06.2012, at 13:43, Sascha Silbe wrote:

> It's quite likely that Etoys doesn't implement its side of the
> essentially undocumented Object Chooser API of Sugar 0.84+ correctly. In
> particular, the object_id parameter of the ObjectChooserResponse signal
> will contain a) the data store object id (currently stored as property
> 'uid') for Journal objects or b) the full path to the file for entries
> stored on external storage media.

That is indeed the first time I hear of that. Yes, Etoys expects the chooser's 
response to be an object_id as per documentation at


http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Choosing_Objects

So you're saying that in the response, the second argument would more properly 
be named object_id_or_full_path. And to distinguish the two cases, we have to 
look at its first character: if it is '/' then it's a path, otherwise an object 
id. 

Are there any other places in the API where instead of an object id we have to 
expect a full path instead?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

Just replying to tie up one loose end here ...

On 01.06.2012, at 07:53, Ajay Garg wrote:

> Thanks Bert.
> 
> 1)
> Bert, I re-compiled after installing all the header- and devel- packages as 
> told by you (after incorporating a blocker-fix as per 
> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/146266).

Ah, the UUID thing. Rats. I brought it up on the upstream dev list again.

I gave you a slightly wrong build requirements list. Instead of uuid-devel you 
need libuuid-devel. And you must uninstall uuid-devel because the build gets 
confused if you have two uuid.h files installed, it chooses the wrong one.

We'll hopefully fix the uuid.h detection properly now ...

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

Hi Ajay,

the entire source code is accessible from Etoys, by pressing the view-source 
key (or ctrl-comma), as I mentioned earlier. Open a System Browser to see the 
entire tree. This is not just a viewer, but you can modify the live system.

Smalltalk (of which Squeak is a dialect) does not use 
source-code-in-text-files. That idea was abandoned back in the early 70ies. 
Instead, we modify objects directly in memory. E.g., adding a method means 
adding a CompiledMethod object to the class object's method dictionary. For 
safety we also log source code changes to a database, but that's only secondary.

The primary means of saving is dumping the whole object memory to disc (that's 
the "etoys.image" file). When loading it back into memory, execution resumes 
exactly where it left off. There is no "main" function, although you register 
certain objects to be notified on resume. That way, the system has been running 
forever. There are objects in it that were created 30 years ago. Which is 
pretty cool, in my opinion, but quite a bit different from most other 
programming systems today.

In any case, Etoys comes with all the Squeak tools to inspect and modify 
itself. The central class managing Sugar integration is called SugarLauncher. 
The entry point is its "startUp" method.

- Bert -

On 02.06.2012, at 07:18, Ajay Garg  wrote:

> Hi Bert.
> 
> 
> 
> Would it be possible for you to provide with the following ::
> 
> a)
> Core etoys-code (the complete source tree is highly desirable :-)  ).
> 
> b)
> Sugar glue-code.
> 
> 
> Thanks and Regards,
> Ajay
> 
> On Fri, Jun 1, 2012 at 11:23 AM, Ajay Garg  wrote:
> Thanks Bert.
> 
> 1)
> Bert, I re-compiled after installing all the header- and devel- packages as 
> told by you (after incorporating a blocker-fix as per 
> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/146266).
> 
> However, I still am not able to hear any sound.
> 
> 
> 2)
> I also tried copying all the so.* files from my Dell laptop (where the sound 
> was being heard) to the XO-1 (where sound is not being heard).
> However, still no sound is heard.
> 
> 
> So, I guess that now, there is some etoys software-hardware 
> intervention-issue that might be blocking the final destination (it must be 
> noted that sound is heard fine, outside the context of etoys).
> 
> 
> Any ideas will be gratefully appreciated; me too is looking into this.
> 
> 
> Thanks and Regards,
> Ajay
> 
> 
> 
> 
> On Fri, Jun 1, 2012 at 2:23 AM, Bert Freudenberg  wrote:
> I sent my patch to the upstream maintainer (Ian Piumarta). I'm hopeful there 
> will be a new 4.x VM release very soon.
> 
> That new release will also help with Scratch because it will have the Scratch 
> plugins (so the Scratch XO bundle do not need any binaries inside anymore), 
> and with Etoys 5 (which needs a new Camera plugin). 4.4.7 already helps DrGeo 
> (which uses a newer Squeak format), and on 64 bit hosts (because many of the 
> 32/64 bit problems have been worked out), and has numerous other improvements.
> 
> Similarly, the dprintf bug you see has been fixed in 2009 according to the 
> change log. It really makes not much sense trying to fix that old codebase. 
> Rather package the new 4.x VM.
> 
> Btw, here is a list of build requirements for squeak-vm (you need to watch 
> the install log to make sure that plugins and features are not disabled 
> because of missing dev headers):
> 
> gcc make cmake pulseaudio-libs-devel alsa-lib-devel nas-devel libogg-devel 
> libvorbis-devel speex-devel uuid-devel dbus-devel pango-devel gstreamer-devel 
> mesa-libGL-devel libX11-devel libXext-devel libXrender-devel freetype-devel
> 
> - Bert -
> 
> PS: I found an MPEG movie that works 
> http://esug.org/data/HistoricalDocuments/Smalltalk80/st80-low.mpg
> 
> On 30.05.2012, at 19:42, Ajay Garg wrote:
> 
> > Thanks Bert.
> > It worked at my side too 
> >
> > The mp3 played fine at my end though :| :)
> >
> > However, I now face the ubiquitous packaging issue. As it stands out, the 
> > src-rpm available is "squeak-vm-3.10.5-5.fc14.src.rpm", which has some very 
> > different installation schemes as compared to the 
> > "http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz"; scheme.
> >
> > Worse, the make for "3.10.5-5" variant fails with the error ::
> >
> > 
> > In file included from 
> > /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:3:0:
> > /usr/include/std

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 28.05.2012, at 21:48, Bert Freudenberg wrote:

> On 28.05.2012, at 20:29, Peter Robinson wrote:
> 
>> As mentioned previously look at the other Activities, like TurtleArt,
>> it works like the rest of the distro translation stuff, I'm not sure
>> if there's other sugar bits that assist with that.
> 
> Other activities have only a single mo file. Other activities use the gettext 
> library so they do not have to worry about where the files are.
> 
> Etoys has multiple mo files. Etoys does not use gettext, so it needs to know 
> where to find the translation files.

I would add that other activities only have translated LC_MESSAGES. Etoys also 
has translated QuickGuides, see its current locale directory.

> It's precisely about those differences I'm asking you for clarification. See 
> my previous message.
> 
> Until now, Etoys just did its own thing, and that worked fine. But there must 
> be a good reason why you want the mo files in the system default directory. 
> (What is that reason, btw?) So I'm trying to find a way to make it happen. If 
> I know what the constraints are, we surely can find a way to make it fit.
> 
> - Bert -


So, what are the constraints?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

I sent my patch to the upstream maintainer (Ian Piumarta). I'm hopeful there 
will be a new 4.x VM release very soon.

That new release will also help with Scratch because it will have the Scratch 
plugins (so the Scratch XO bundle do not need any binaries inside anymore), and 
with Etoys 5 (which needs a new Camera plugin). 4.4.7 already helps DrGeo 
(which uses a newer Squeak format), and on 64 bit hosts (because many of the 
32/64 bit problems have been worked out), and has numerous other improvements.

Similarly, the dprintf bug you see has been fixed in 2009 according to the 
change log. It really makes not much sense trying to fix that old codebase. 
Rather package the new 4.x VM.

Btw, here is a list of build requirements for squeak-vm (you need to watch the 
install log to make sure that plugins and features are not disabled because of 
missing dev headers):

gcc make cmake pulseaudio-libs-devel alsa-lib-devel nas-devel libogg-devel 
libvorbis-devel speex-devel uuid-devel dbus-devel pango-devel gstreamer-devel 
mesa-libGL-devel libX11-devel libXext-devel libXrender-devel freetype-devel

- Bert -

PS: I found an MPEG movie that works 
http://esug.org/data/HistoricalDocuments/Smalltalk80/st80-low.mpg

On 30.05.2012, at 19:42, Ajay Garg wrote:

> Thanks Bert.
> It worked at my side too 
> 
> The mp3 played fine at my end though :| :)
> 
> However, I now face the ubiquitous packaging issue. As it stands out, the 
> src-rpm available is "squeak-vm-3.10.5-5.fc14.src.rpm", which has some very 
> different installation schemes as compared to the 
> "http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz"; scheme. 
> 
> Worse, the make for "3.10.5-5" variant fails with the error ::
> 
> 
> In file included from 
> /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:3:0:
> /usr/include/stdio.h:419:66: error: macro "dprintf" passed 3 arguments, but 
> takes just 1
> /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c: In 
> function ‘__sq_assert’:
> /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:21:3: 
> warning: incompatible implicit declaration of built-in function ‘abort’
> make[1]: *** [debug.o] Error 1
> make: *** [vm/vm.a] Error 2
> 
> 
> 
> 
> So, does there exist a way to make a rpm out of "4.4.7.2357" variant, with 
> the "Mpeg3Plugin/config.cmake" patch applied?
> 
> 
> Thanks a ton for your time.
> 
> 
> Thanks and Regards,
> Ajay

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 31.05.2012, at 20:02, Ajay Garg wrote:

> On Thu, May 31, 2012 at 11:24 PM, Bert Freudenberg  
> wrote:
>> On 31.05.2012, at 19:33, Ajay Garg wrote:
>> 
>>> However, when I press "Play", NOTHING happens. I don't hear any sound, nor 
>>> do I see any error (The mp3 is fine otherwise, it playes well via 
>>> gst-launch).
>>> 
>> Well, does sound work in Etoys otherwise? Like, in the car's viewer, if you 
>> click the yellow exclamation mark button next to "car make sound", do you 
>> hear anything?
> 
> Also, when I press the exclamation mark - set in between "Car script1" and 
> "ticking" - I hear no sound.

Okay, so sound output is broken.

> Any quick idea ?
> Otherwise I am going into the depths pointed by you :D

The Squeak tools are unlikely to help in this case. Sounds more like a VM 
problem - make sure the right sound module is selected (ALSA or OSS or Pulse). 
See the /usr/bin/etoys script and "squeak -help". The VM is just a C program 
that you debug pretty much like any other C program (even though parts of it 
are generated from Squeak code).

Also, if you compiled the VM yourself, pay attention to the configure output. 
If you do not have the right dev packages installed, some modules will be 
disabled and do not get built.

Also note there are various tickets regarding sound on d.l.o.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 31.05.2012, at 19:33, Ajay Garg wrote:

> Ok,
> 
> After much of head-banging, I finally compared the strace dumps from my Dell 
> laptop, and my XO-1.
> I noted that, that on Dell, squeakvm was being launched from 
> "/usr/local/lib", while on XO-1, from "/usr/bin".
> 
> I made the required changes, and surprisingly, everything fell in place.
> 
> Well.. only to the point of starting the etoys :\
> 
> 
> Now, upon launching the sugar-etoys, and navigating to "Supplies" -> "Object 
> Catalog" -> "Multimedia" -> "MPEGPlayer" -> "Open" -> "Choosing a file" -> 
> "Clicking OK", thankfully, the "abandon" error is no more seen :) :) :)
> 
> However, when I press "Play", NOTHING happens. I don't hear any sound, nor do 
> I see any error (The mp3 is fine otherwise, it playes well via gst-launch).

Well, does sound work in Etoys otherwise? Like, in the car's viewer, if you 
click the yellow exclamation mark button next to "car make sound", do you hear 
anything?

Also, the position slider should start moving.

> Bert, is there a mechanism wherein I can see SOMEthing, which may give a clue 
> as to why no sound can be heard (even an error somewhere here and there might 
> be useful, but it needs to be seen first :D )

Well, you have the full Squeak development environment at your disposal, if you 
care to learn how to use it ;)

You can press the view-source key on the XO, or Control-Comma. That gives you 
access to the dev tools. Execute any code you see or type anywhere by pressing 
Control-D (or Control-P or Control-I, just try the difference on "3+4", for 
example).

Also, you should enable the "debugHaloHandle" preference. Then right-clicking 
will give you a wrench icon in the halo, that lets you explore the object on 
screen. (I usually keep this enabled using the "set automatically on 
startup..." preference menu item)

If you have an object selected in the object explorer, press ctrl-b to open a 
source code browser. Or click the middle mouse button to bring up a menu 
(control-click works if you only have two buttons).

That's pretty much all you need to figure out what's going on :)

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 30.05.2012, at 13:55, Ajay Garg wrote:

> Same result.
> 
> Following are the locations of candidate files :::
> 
> 
> [ajay@localhost ~]$ ls -l /usr/lib/squeak/3.10-5/
> -rwxr-xr-x. 1 root root 674862 May 30 17:24 Mpeg3Plugin
> 
> 

This one should have been sufficient. You're right, it does not work. There is 
a genuine problem.

So I checked. I recompiled the VM after setting DEBUG to 1 in 
unix/vm/sqUnixExternalPrims.c which shows what's happening when Squeak tries to 
load the plugin.

The plugin is missing a few functions, which makes it fail to load. I found one 
C file that is not included when building the plugin.

This likely happened in 2009 when we switched to CMake. Which shows that nobody 
else except kids in UY are using the Mpeg3Plugin ;)

It would be much better if you included a real mp3 player in your OS, and not 
rely on the Squeak one ...

I'm not quite sure what the right fix is, but a workaround is to add 
"${src}/plugins/Mpeg3Plugin/Mpeg3Plugin.c" to the ${plugin}_sources LIST in 
unix/plugins/Mpeg3Plugin/config.cmake

After adding that line and rebuilding, the plugin works fine in the 4.4.7 VM. I 
did not try in the 3.10 VM but it should work too. 

The MP3 I tried played too fast. Not quite sure why that is, but that's enough 
investigating for me for now ...

(And don't bother with MPEG videos. There are only very few that play in this 
plugin. It's not a general-purpose MPEG video player)

- Bert -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 30.05.2012, at 12:49, Ajay Garg wrote:

> 
> 
> On Wed, May 30, 2012 at 4:09 PM, Bert Freudenberg  
> wrote:
> Did you move the plugin to where the other plugins are, and possibly renamed 
> it to match the other plugins name scheme?
> 
> Yes, tried the following variants ::
> 
> * /usr/local/lib/libMpeg3Plugin.so
> * /usr/local/lib/Mpeg3Plugin.so
> * /usr/lib/libMpeg3Plugin.so
> * /usr/lib/Mpeg3Plugin.so

Put it in the squeak plugins folder /usr/lib/squeak/...

- Bert -

>  
> 
> Also, are you sure that "DELTA.MPG" actually is an mp3 file?
> 
> No, this is a MPEG file.
> The same happens with a true mp3 file as well.
> 
> 
> Regards,
> Ajay 
> 
> - Bert -
> 
> On 30.05.2012, at 10:53, Ajay Garg wrote:
> 
>> For brevity, here is the complete stacktrace (picked from shell command 
>> line) ::
>> 
>> 
>> ##
>> === SqueakDebug.log START ==
>> Error: a primitive has failed
>> 30 May 2012 2:21 pm
>> 
>> VM: unix - a SmalltalkImage
>> Image: etoys4.1 [latest update: #2390]
>> 
>> SecurityManager state:
>> Restricted: false
>> FileAccess: true
>> SocketAccess: true
>> Working Dir /home/ajay/Etoys
>> Trusted Dir /home/ajay/.etoys/private
>> Untrusted Dir /home/ajay/Etoys
>> 
>> MPEGFile class(Object)>>error:
>> Receiver: MPEGFile
>> Arguments and temporary variables: 
>> aString: 'a primitive has failed'
>> Receiver's instance variables: 
>> superclass: Object
>> methodDict: a MethodDictionary(#audioChannels:->a CompiledMethod 
>> (1113) #audioG...etc...
>> format: 138
>> instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
>> 'endianness')
>> organization: ('access' endianness fileHandle fileName 
>> getPercentage getTOC:doS...etc...
>> subclasses: nil
>> name: #MPEGFile
>> classPool: a Dictionary(#Registry->nil )
>> sharedPools: nil
>> environment: a SystemDictionary(lots of globals)
>> category: nil
>> 
>> MPEGFile class(Object)>>primitiveFailed
>> Receiver: MPEGFile
>> Arguments and temporary variables: 
>> 
>> Receiver's instance variables: 
>> superclass: Object
>> methodDict: a MethodDictionary(#audioChannels:->a CompiledMethod 
>> (1113) #audioG...etc...
>> format: 138
>> instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
>> 'endianness')
>> organization: ('access' endianness fileHandle fileName 
>> getPercentage getTOC:doS...etc...
>> subclasses: nil
>> name: #MPEGFile
>> classPool: a Dictionary(#Registry->nil )
>> sharedPools: nil
>> environment: a SystemDictionary(lots of globals)
>> category: nil
>> 
>> MPEGFile class>>primFileValidMPEG:
>> Receiver: MPEGFile
>> Arguments and temporary variables: 
>> aPath: '/home/ajay/Desktop/DELTA.MPG'
>> Receiver's instance variables: 
>> superclass: Object
>> methodDict: a MethodDictionary(#audioChannels:->a CompiledMethod 
>> (1113) #audioG...etc...
>> format: 138
>> instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
>> 'endianness')
>> organization: ('access' endianness fileHandle fileName 
>> getPercentage getTOC:doS...etc...
>> subclasses: nil
>> name: #MPEGFile
>> classPool: a Dictionary(#Registry->nil )
>> sharedPools: nil
>> environment: a SystemDictionary(lots of globals)
>> category: nil
>> 
>> MPEGFile class>>isFileValidMPEG:
>> Receiver: MPEGFile
>> Arguments and temporary variables: 
>> path: '/home/ajay/Desktop/DELTA.MPG'
>> Receiver's instance variables: 
>> superclass: Object
>> methodDict: a MethodDictionary(#audioChannels:->a CompiledMethod 
>> (1113) #audioG...etc...
>> format: 138
>> instanceVariables: #('pathToFile&#

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

 SimpleButtonMorph(Morph)>>handleMouseUp:
> MouseButtonEvent>>sentTo:
> SimpleButtonMorph(Morph)>>handleEvent:
> SimpleButtonMorph(Morph)>>handleFocusEvent:
> [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.  ActiveEvent 
> := anEvent.  result := focusHolder han...]}
> [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
> BlockContext>>on:do:
> PasteUpMorph>>becomeActiveDuring:
> HandMorph>>sendFocusEvent:to:clear:
> HandMorph>>sendEvent:focus:clear:
> HandMorph>>sendMouseEvent:
> HandMorph>>handleEvent:
> HandMorph>>processEvents
> [] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h 
> processEvents.  capturingGesture := capturingGest...]}
> Array(SequenceableCollection)>>do:
> WorldState>>handsDo:
> WorldState>>doOneCycleNowFor:
> WorldState>>doOneCycleFor:
> PasteUpMorph>>doOneCycle
> [] in Project class>>spawnNewProcess {[[World doOneCycle.  Processor yield.  
> false] whileFalse.  nil]}
> [] in BlockContext>>newProcess {[self value.  Processor terminateActive]}
> ######
> 
> On Wed, May 30, 2012 at 10:59 AM, Ajay Garg  wrote:
> Thanks Bert for the reply.
> 
> I downloaded the source from 
> http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz, did "make" 
> and "sudo make install".
> 
> It seemed to work, but there was no improvement while playing "Supplies" -> 
> "Object Catalogue" -> "Multimedia" -> "MPEGPlayer" ->''DELTA.MPG".
> 
> One thing I noted that all plugins file are of form "so.*", whereas I believe 
> that in unix they should be of the form "*.so". For example, the generated 
> Mpeg3Plugin file is "so.Mpeg3Plugin", and not "Mpeg3Plugin.so" - something 
> which is expected for shared-object files in the unix world.
> 
> Am I missing something?
> 
> 
> Thanks and Regards,
> Ajay
> 
> 
> On Wed, May 30, 2012 at 2:25 AM, Bert Freudenberg  
> wrote:
> So problem a) is Sugar, problem b) squeak. I'll ignore a). For b):
> 
> You do not need gstreamer, but rather Squeak's Mpeg3Plugin which has its own 
> decoder. This is not shipped in Fedora due to mp3 licensing concerns. You 
> need to copy it from an old UY bundle (there might be a x86 copy in some 
> tracker ticket on d.l.o). If need be you can also compile it from a Squeak VM 
> source tar ball (likely needed for ARM).
> 
> - Bert -
> 
> On 29.05.2012, at 22:26, Ajay Garg  wrote:
> 
>> Well, there are two different issues ::
>> 
>> a)
>> First is the data-store issue.
>> 
>> As seen from the logs, the (mp3) file that was opened, was present in a USB 
>> pen drive.
>> ANY ENTRY, when accessed via USB-pen-drive, will give this error (i.e. mp3, 
>> jpeg, png - any file).
>> 
>> CAUSE ::
>> ===
>> 
>> The code in "carquinol" package, presumes the data-to-be-accessed coming 
>> from the journal.
>> 
>> 
>> 
>> SOLUTION ::
>> ==
>> 
>> As happens with all entries that are accessed from USB pen-drives, these 
>> entries too need to be copied first to the journal, to maintain 
>> compatability.
>> 
>> 
>> 
>> SOLUTION-IMPLEMENTATION-REQUIREMENT ::
>> =
>> 
>> The "etoys-sugar-code" is needed, wherein a flag may be passed to 
>> objectchooser, to copy the file to the journal if invoked from etoys; and 
>> subsequently access the journal-entry thereafter.
>> 
>> Bert, we will be grateful if you could provide the code-location for this.
>> 
>> 
>> 
>> 
>> 
>> b)
>> The second issue is the sound not playing.
>> 
>> I ensured that the following packages were installed on my non-XO laptop 
>> (Dell-F14-laptop) ::
>> 
>> * gstreamer-plugins-bad
>> * gstreamer-plugins-ugly
>> * gstreamer-ffmpeg
>> * etoys
>> * squeak-vm
>> * squeak-vm-nonXOplugins
>> 
>> Thereafter, I downloaded the following MPEG file ::
>> http://samples.fileformat.info/format/mpeg/sample/567fd6a0e0da4a8e81bdeb870de3b19c/DELTA.MPG?AWSAccessKeyId=0V91BEFA7GM093MEVMG2&Signature=zvF6p5NE3Jz3oSKtyw2obyPosDQ%3D&Expires=133835
>> 
>> 
>> and tried playing via "Supplies" -> "Object Catalogue" -> "Multimedia" -> 
>> "MPEGPlayer". However, I got the same &qu

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

So problem a) is Sugar, problem b) squeak. I'll ignore a). For b):

You do not need gstreamer, but rather Squeak's Mpeg3Plugin which has its own 
decoder. This is not shipped in Fedora due to mp3 licensing concerns. You need 
to copy it from an old UY bundle (there might be a x86 copy in some tracker 
ticket on d.l.o). If need be you can also compile it from a Squeak VM source 
tar ball (likely needed for ARM).

- Bert -

On 29.05.2012, at 22:26, Ajay Garg  wrote:

> Well, there are two different issues ::
> 
> a)
> First is the data-store issue.
> 
> As seen from the logs, the (mp3) file that was opened, was present in a USB 
> pen drive.
> ANY ENTRY, when accessed via USB-pen-drive, will give this error (i.e. mp3, 
> jpeg, png - any file).
> 
> CAUSE ::
> ===
> 
> The code in "carquinol" package, presumes the data-to-be-accessed coming from 
> the journal.
> 
> 
> 
> SOLUTION ::
> ==
> 
> As happens with all entries that are accessed from USB pen-drives, these 
> entries too need to be copied first to the journal, to maintain compatability.
> 
> 
> 
> SOLUTION-IMPLEMENTATION-REQUIREMENT ::
> =
> 
> The "etoys-sugar-code" is needed, wherein a flag may be passed to 
> objectchooser, to copy the file to the journal if invoked from etoys; and 
> subsequently access the journal-entry thereafter.
> 
> Bert, we will be grateful if you could provide the code-location for this.
> 
> 
> 
> 
> 
> b)
> The second issue is the sound not playing.
> 
> I ensured that the following packages were installed on my non-XO laptop 
> (Dell-F14-laptop) ::
> 
> * gstreamer-plugins-bad
> * gstreamer-plugins-ugly
> * gstreamer-ffmpeg
> * etoys
> * squeak-vm
> * squeak-vm-nonXOplugins
> 
> Thereafter, I downloaded the following MPEG file ::
> http://samples.fileformat.info/format/mpeg/sample/567fd6a0e0da4a8e81bdeb870de3b19c/DELTA.MPG?AWSAccessKeyId=0V91BEFA7GM093MEVMG2&Signature=zvF6p5NE3Jz3oSKtyw2obyPosDQ%3D&Expires=133835
> 
> 
> and tried playing via "Supplies" -> "Object Catalogue" -> "Multimedia" -> 
> "MPEGPlayer". However, I got the same "abandon" error, with the second-last, 
> and third-last stack-point error as follows ::
> 
> #
> primitiveFailed
> "Announce that a primitive has failed and there is no appropriate 
> Smalltalk code to run."
> 
> self error: 'a primitive has failed'
> 
> 
> primFileValidMPEG: aPath
> "Check to see if the file is valid"
> 
> self primitiveFailed
> #
> 
> 
> 
> SOLUTION ::
> =
> 
> I guess there is still some plugin missing on my Dell laptop.
> But I have gone out of ideas to try.
> 
> Bert, we will again be grateful :)
> 
> 
> 
> 
> Thanks and Regards,
> Ajay
> 
> 
> On Sun, May 27, 2012 at 2:10 AM, Rafael Ortiz  
> wrote:
> 
> 
> On Sat, May 26, 2012 at 12:13 PM, Rafael Ortiz  
> wrote:
> 
> 
> On Sat, May 26, 2012 at 7:47 AM, Peter Robinson  wrote:
> On Sat, May 26, 2012 at 12:54 PM, Bert Freudenberg  
> wrote:
> >
> > On 25.05.2012, at 22:21, Rafael Ortiz wrote:
> >
> >
> >
> > On Thu, May 24, 2012 at 11:34 AM, Rafael Ortiz 
> > wrote:
> >>
> >> Hi
> >>
> >> While trying to add a journal entry (mp3 file) from etoys-113, i'm getting
> >> ."An error has occurred; you should probably just hit abandon. Sorry"
> >>
> >> Is this known?
> >>
> >> Log attached
> >>
> >
> > A clue on what this might be happening and how to solve it, appreciated.
> >
> > Thanks :)
> >
> >
> > Well, the relevant lines in the error log seem to be these:
> >
> > DBusError: Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/dbus/service.py", line 702, in
> > _message_cb
> > retval = candidate_method(self, *args, **keywords)
> >   File "/usr/lib/python2.7/site-packages/carquinyol/datastore.py", line 355,
> > in get_properties
> > metadata = self._metadata_store.retrieve(uid)
> >   File "/usr/lib/python2.7/site-packages/carquinyol/metadatastore.py", line
> > 41, in retrieve
> > return metadatareader.retrieve(metadata_path, properties)
> > IOError: Couldn't open metadata directory
> > /home/olpc/.sugar/default/datastore//m//media/Philips/Buen

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 29.05.2012, at 17:10, Gonzalo Odiard wrote:

>> Until now, Etoys just did its own thing, and that worked fine. But there 
>> must be a good reason why you want the mo files in the system default 
>> directory. (What is that reason, btw?) So I'm trying to find a way to make 
>> it happen. If I know what the constraints are, we surely can find a way to 
>> make it fit.
> 
> While you are looking at this, check if you can rename the file Sugar.po, 
> because will conflict with the file used by the sugar module.
> 
> Gonzalo 

That's why I was suggesting to prefix the mo file names:

>> Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
>> Connectors.mo, etc. [...] I would propose to rename them to 
>> Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 


Do you think the po file names need to be prefixed, too? I though I could add 
the prefix when generating the mo files from the source po files.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 29.05.2012, at 17:10, Gonzalo Odiard wrote:

>> Until now, Etoys just did its own thing, and that worked fine. But there 
>> must be a good reason why you want the mo files in the system default 
>> directory. (What is that reason, btw?) So I'm trying to find a way to make 
>> it happen. If I know what the constraints are, we surely can find a way to 
>> make it fit.
> 
> While you are looking at this, check if you can rename the file Sugar.po, 
> because will conflict with the file used by the sugar module.
> 
> Gonzalo 

That's why I was suggesting to prefix the mo file names:

>> Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
>> Connectors.mo, etc. [...] I would propose to rename them to 
>> Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 


Do you think the po file names need to be prefixed, too? I though I could add 
the prefix when generating the mo files from the source po files.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 29.05.2012, at 17:10, Gonzalo Odiard wrote:

>> Until now, Etoys just did its own thing, and that worked fine. But there 
>> must be a good reason why you want the mo files in the system default 
>> directory. (What is that reason, btw?) So I'm trying to find a way to make 
>> it happen. If I know what the constraints are, we surely can find a way to 
>> make it fit.
> 
> While you are looking at this, check if you can rename the file Sugar.po, 
> because will conflict with the file used by the sugar module.
> 
> Gonzalo 

That's why I was suggesting to prefix the mo file names:

>> Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
>> Connectors.mo, etc. [...] I would propose to rename them to 
>> Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 


Do you think the po file names need to be prefixed, too? I though I could add 
the prefix when generating the mo files from the source po files.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys translations (was: Etoys in RC4 SoaS-v7 does not start when jabber is connected.)

[Bert Freudenberg]

On 28.05.2012, at 20:29, Peter Robinson wrote:

> On Mon, May 28, 2012 at 7:15 PM, Bert Freudenberg  
> wrote:
>> On 28.05.2012, at 19:54, Peter Robinson wrote:
>> 
>>> symlinks don't work with the Fedora packaging language tools, I prefer
>>> that as it's what the rest of the sugar stack works with.
>> 
>> The way I imagine it is that the .mo files would be installed in 
>> /usr/share/locale as all the other packages do, too.
>> 
>> The only question is how to let Etoys know where to go look for its locale 
>> files. A symlink created by the installation script would be the simplest 
>> solution IMHO. Otherwise we would have to try to pass the directory as 
>> argument to etoys in its launcher script which to me seems overly 
>> complicated.
>> 
>>>> If we prefix all Etoys .mo files then they could be installed to the 
>>>> system folder.
>>> 
>>> If you use the usual flags as used by all packages for Linux distros
>>> it means you're standard and it will work with all the various linux
>>> distro options.
>>> 
>>> Peter
>> 
>> Not sure what you mean by flags. What I mean by prefixes is this:
>> 
>> Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
>> Connectors.mo, etc. This works fine because Etoys had the whole LC_MESSAGES 
>> directory for itself. I would propose to rename them to 
>> Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 
>> because if we share the same directory with other packages it would be hard 
>> to identify which mo files belong to Etoys.
> 
> As mentioned previously look at the other Activities, like TurtleArt,
> it works like the rest of the distro translation stuff, I'm not sure
> if there's other sugar bits that assist with that.


Other activities have only a single mo file. Other activities use the gettext 
library so they do not have to worry about where the files are.

Etoys has multiple mo files. Etoys does not use gettext, so it needs to know 
where to find the translation files.

It's precisely about those differences I'm asking you for clarification. See my 
previous message.

Until now, Etoys just did its own thing, and that worked fine. But there must 
be a good reason why you want the mo files in the system default directory. 
(What is that reason, btw?) So I'm trying to find a way to make it happen. If I 
know what the constraints are, we surely can find a way to make it fit.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Etoys translations (was: Etoys in RC4 SoaS-v7 does not start when jabber is connected.)

[Bert Freudenberg]

On 28.05.2012, at 19:54, Peter Robinson wrote:

> symlinks don't work with the Fedora packaging language tools, I prefer
> that as it's what the rest of the sugar stack works with.

The way I imagine it is that the .mo files would be installed in 
/usr/share/locale as all the other packages do, too.

The only question is how to let Etoys know where to go look for its locale 
files. A symlink created by the installation script would be the simplest 
solution IMHO. Otherwise we would have to try to pass the directory as argument 
to etoys in its launcher script which to me seems overly complicated.

>> If we prefix all Etoys .mo files then they could be installed to the system 
>> folder.
> 
> If you use the usual flags as used by all packages for Linux distros
> it means you're standard and it will work with all the various linux
> distro options.
> 
> Peter

Not sure what you mean by flags. What I mean by prefixes is this:

Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
Connectors.mo, etc. This works fine because Etoys had the whole LC_MESSAGES 
directory for itself. I would propose to rename them to Etoys-Collections.mo, 
Etoys-Compression.mo, Etoys-Connectors.mo, etc. because if we share the same 
directory with other packages it would be hard to identify which mo files 
belong to Etoys.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 19:06, Peter Robinson wrote:

> On Mon, May 28, 2012 at 5:49 PM, Bert Freudenberg  
> wrote:
>> 
>> What else can we do besides fixing issues and hoping you package the result? 
>> That's our take on trying to "actively improve the situation".
>> 
>> Again, Etoys 5 starts fine, Etoys 4.1 not. But we cannot really test distro 
>> stuff if it has not been packaged yet.
> 
> The last release I remember seeing was an RC (don't remember if it was
> RC1 or 2) and I had issues and never got back to it and if I must have
> missed the final release.

I had assumed you would package even release candidates so they can be tested 
in the distro.

The final release is the last release candidate, Etoys 5.0.2406. I failed to 
send a separate notice for that, sorry.

>  Ultimately it would be nice if the
> developers of their Activities checked and tested and emailed the SoaS
> list if they have issues or the new versions have been missed.

Okay. I didn't want to bug you immediately, and after a while forgot.

> We have
> nightly builds right through the dev process and various
> Alpha/Beta/RCs etc in the lead up to final for testing. I can't test
> everything and I'm not fallible and the process we use has clearly
> defined [1] development schedule to know when fixes need to be in by.

I did send the release announcement on March 30th, so that should have been 
fine for the F17 beta.

>> Regarding the locale directory layout: I did not find a ticket in any of the 
>> trackers, neither upstream nor at sugarlabs or olpc. What would make the 
>> packaging easier for you?
> 
> To use the same layout that is used by everything else so we can use
> the standard distro tools to deal with them. Probably the best package
> to look at is TurtleArt.

Would a symlink be acceptable? This would make it easier for Etoys to find the 
right system folder.

/usr/share/etoys/locale -> ../../locale

(would resolve to /usr/share/locale)

If we prefix all Etoys .mo files then they could be installed to the system 
folder.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 18:19, Peter Robinson wrote:

> On Mon, May 28, 2012 at 5:05 PM, Walter Bender  
> wrote:
>> On Mon, May 28, 2012 at 10:57 AM, Peter Robinson  
>> wrote:
>>> On Mon, May 28, 2012 at 3:30 PM, Bert Freudenberg  
>>> wrote:
>>>> 
>>>> On 28.05.2012, at 15:52, Peter Robinson wrote:
>>>> 
>>>>> On Mon, May 28, 2012 at 2:50 PM, Bert Freudenberg  
>>>>> wrote:
>>>>>> SoaS still has the old Etoys version (4.1). Etoys 5 was released along 
>>>>>> with Sugar 0.96. It is more robust wrt presence service failures.
>>>>> 
>>>>> it also still needs the sugar-presence-service package which has been 
>>>>> obsolete for a long
>>>>> time.
>>>> 
>>>> 
>>>> Etoys 5 is no worse than previous versions in that respect. On the 
>>>> contrary, it deals better with presence service deterioration.
>>>> 
>>>> Re-implementing the presence service takes time, I'm on my own, can't make 
>>>> it happen soon.
>>> 
>>> I think it's been over 2 years, I might just drop eToys from the build
>>> because it always causes random issues.
>> 
>> Peter,
>> 
>> I urge you to not drop Etoys. It is one of the most powerful learning
>> tools we offer. Sugar is greatly diminished without it. Are there open
>> tickets on these random issues?
> 
> Well it would be nice if the developers actively participated and
> tested in the process. We've had these issues on going for as long as
> I can remember and they never get the attention that they need for
> "one of the most powerful learning tools we offer" and mostly just
> causes me pain.
> 
> It's not too late to fix for the core SoaS v7 release so it gives
> people 6 months to actively improve the situation for the next
> release.
> 
> Peter


I, too, hope you threaten to drop Etoys just to illustrate your frustration.

What else can we do besides fixing issues and hoping you package the result? 
That's our take on trying to "actively improve the situation". 

Again, Etoys 5 starts fine, Etoys 4.1 not. But we cannot really test distro 
stuff if it has not been packaged yet.

Regarding the locale directory layout: I did not find a ticket in any of the 
trackers, neither upstream nor at sugarlabs or olpc. What would make the 
packaging easier for you?

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 15:52, Peter Robinson wrote:

> On Mon, May 28, 2012 at 2:50 PM, Bert Freudenberg  
> wrote:
>> SoaS still has the old Etoys version (4.1). Etoys 5 was released along with 
>> Sugar 0.96. It is more robust wrt presence service failures.
> 
> it also still needs the sugar-presence-service package which has been 
> obsolete for a long
> time.


Etoys 5 is no worse than previous versions in that respect. On the contrary, it 
deals better with presence service deterioration.

Re-implementing the presence service takes time, I'm on my own, can't make it 
happen soon.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 15:52, Peter Robinson wrote:

> On Mon, May 28, 2012 at 2:50 PM, Bert Freudenberg  
> wrote:
>> SoaS still has the old Etoys version (4.1). Etoys 5 was released along with 
>> Sugar 0.96. It is more robust wrt presence service failures.
> 
> It has issues with translations and the non standard location it installs them


Why is that a problem? Seems to have worked fine so far - and nothing else but 
Etoys is using these translation files.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 27.05.2012, at 19:41, Thomas C Gilliard wrote:

> On 05/27/2012 05:37 AM, Peter Robinson wrote:
>> On Thu, May 24, 2012 at 4:56 PM, Thomas C Gilliard
>>   wrote:
>>> I have been testing the RC4 f17 release of SoaS [1] and I see a problem with
>>> e-toys:
>>> If jabber.sugarlabs.org  is connected via a wireless AP, or wired network,
>>> e-toys will not start:
>>> 
>>>  DBusError: Process /usr/bin/sugar-presence-service exited with status 1
>>> 
>>> Etoys runs fine if wireless is not logged in and/or wired network is not
>>> connected. (no jabber connected)
>>> 
>>> As Etoys is a favorite on the f3 ring and f17 release is imminent, I feel
>>> that this is an important bug to look at.
>> Sorry, it was reported too late. It should have also been reported to
>> the soas list.
> I have been reporting this occasional failure, But only realized what was 
> causing this behavior 3 days ago. : (
> 
> It is possible to use E-toys but the DBusError created by the starting 
> example is very distracting. See bugs.sugarlabs.org/ticket/3640#comment:1
> 
> The start up example seems to require process /usr/bin/sugar-presence-service


SoaS still has the old Etoys version (4.1). Etoys 5 was released along with 
Sugar 0.96. It is more robust wrt presence service failures.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 25.05.2012, at 22:21, Rafael Ortiz wrote:

> 
> 
> On Thu, May 24, 2012 at 11:34 AM, Rafael Ortiz  
> wrote:
> Hi 
> 
> While trying to add a journal entry (mp3 file) from etoys-113, i'm getting 
> ."An error has occurred; you should probably just hit abandon. Sorry"
> 
> Is this known?
> 
> Log attached
> 
> 
> A clue on what this might be happening and how to solve it, appreciated.
> 
> Thanks :)

Well, the relevant lines in the error log seem to be these:

DBusError: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/dbus/service.py", line 702, in 
_message_cb
retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python2.7/site-packages/carquinyol/datastore.py", line 355, in 
get_properties
metadata = self._metadata_store.retrieve(uid)
  File "/usr/lib/python2.7/site-packages/carquinyol/metadatastore.py", line 41, 
in retrieve
return metadatareader.retrieve(metadata_path, properties)
IOError: Couldn't open metadata directory 
/home/olpc/.sugar/default/datastore//m//media/Philips/Buenos Muchachos/Se Pule 
La Colmena/2-06 Corazonoro.mp3/metadata

So apparently Etoys tries to access the metadata for the MP3 but the datastore 
fails to find it. Etoys does not handle that case, it relies on 
get_properties() succeeding. Is that wrong?

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

On 20.05.2012, at 20:38, Hilaire Fernandes wrote:

> I will give it a shot later these days. These various tries where useful
> to surround the  problem.
> 
> Hilaire


I asked on the VM dev list. Dave Lewis had a hunch that possibly Pharo's object 
memory is corrupt:

http://lists.squeak.org/pipermail/vm-dev/2012-May/010652.html

In any case it wouldn't hurt to ask for help on the Pharo list.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

On 20.05.2012, at 11:00, Sascha Silbe wrote:

> Bert Freudenberg  writes:
> 
>> Nope, that was not it. I compiled with -mtune=geode, makes no
>> difference.
> 
> Make sure to set -march= to something appropriate. -march
> tells gcc what instructions it can use (so anything that doesn't support
> these instructions will fail to run the resulting executable), whereas
> -mtune only tells it to optimise for a certain processor type (but the
> executable will continue to run on other processors as long as they
> support the instruction set specified by -march).

I actually had used "-march=pentiumpro -mtune=geode" as recommended here:

http://wiki.laptop.org/go/Geode_LX

and even with an additional -O0 it still crashes.

> In gdb I see it's segfaulting inside the GC logic. It's really
>> puzzling this only happens on the XO-1 ...
> 
> You could try booting an XO-1.5 with mem=256M (append that to boot-file
> in /bootpart/boot/olpc.fth) to simulate the memory pressure of an XO-1.


YES! That reproduces the crash on XO-1.5. Good thinking! :)

I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no 
swap. Top reports:

Mem:766204k total,   601588k used,   164616k free,45624k buffers
Swap:0k total,0k used,0k free,   277024k cached

but DrGeo still crashes.

OTOH, Etoys runs fine using the same Squeak VM on the same system (and on 
XO-1). So I wonder what the new DrGeo does differently ...

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

Nope, that was not it. I compiled with -mtune=geode, makes no difference.

In gdb I see it's segfaulting inside the GC logic. It's really puzzling this 
only happens on the XO-1 ...

- Bert -

On 19.05.2012, at 23:15, Bert Freudenberg wrote:

> The trace is not enlightening.
> 
> I'll take a shot in the dark:
> 
> I vaguely remember the XO-1's AMD Geode processor lacks some features that 
> other x86 CPUs have. Do I remember correctly? If that is so, could you try 
> compiling the VM in i386 compatibility mode? I don't recall how to do that, 
> it's been too long ago ...
> 
> - Bert -
> 
> On 19.05.2012, at 23:01, Ariel Calzada wrote:
> 
>> Hi Bert!
>> 
>> Yes I compiled 4.4.7 and this doesn't work with drgeo.image, i tested with 
>> pharo 1.3 image and it worked. Logs attached.
>> 
>> Regards,
>> Ariel Calzada
>> Activity Central
>> 
>> On 05/19/2012 03:57 PM, Bert Freudenberg wrote:
>>> 
>>> Hi Ariel,
>>> 
>>> there are messages missing from this thread. I did not see the message with 
>>> your trace attachments.
>>> 
>>> But, are you saying you compiled the 4.4.7 Squeak VM on an old Fedora and 
>>> it still does not work with DrGeo on an XO-1?
>>> 
>>> - Bert -
>>> 
>>> On 19.05.2012, at 21:47, Ariel Calzada wrote:
>>> 
>>>> Hi!
>>>> 
>>>> I downloaded it pharo image from 
>>>> http://www.pharo-project.org/pharo-download/release-1-4, and got the same 
>>>> error message. Is there any other test that i can do in order to fix the 
>>>> error?.
>>>> 
>>>> Regards,
>>>> Ariel Calzada
>>>> Activity Central
>>>> 
>>>> 2012/5/19 Hilaire Fernandes 
>>>> This VM was used with previous version of DrGeo.
>>>> Is the problem related to the latest stable Sugar and the VM and XO-1?
>>>> I tested DrGeo 11.08 and it worked with this identical set up.
>>>> So It could be related to the Pharo image I used, or all related together.
>>>> It is not easy to track the exact problem and it may take time.
>>>> 
>>>> One things to do could be to test latest, virgin, Pharo image 1.4 with
>>>> this same image., so it could clarify the problem
>>>> 
>>>> Hilaire
>>>> 
>>>> 
>>>> 
>>>> On 19/05/2012 20:10, Ariel Calzada wrote:
>>>> > Hi!
>>>> >
>>>> > We have made the following tests for XO 1.0:
>>>> >
>>>> > -- Run squeak binary  strace ./squeak drgeo.image ( Attachment:
>>>> > strace-binary.txt )
>>>> > -- Run squeak compiled  strace ./squeak drgeo.image ( Attachment:
>>>> > strace-src.txt )
>>>> >
>>>> > Both tests were not successful we got segmentation fault errors, we had
>>>> > review the strace logs but we haven't found why this happen.
>>>> >
>>>> > I hope this helps.
>>>> >
>>>> > Regards,
>>>> > Ariel Calzada
>>>> > Activity Central
>>>> >
>>>> >
>>>> > 2012/5/16 Hilaire Fernandes 
>>>> >
>>>> >> It looks like the SqueakVM I compiled for DrGeo  does not work with X0-1
>>>> >> last Sugar system, but ok with XO-1.5 last Sugar system.
>>>> >>
>>>> >> It will cost me too much to prepare a new VM, I am busy with tablet
>>>> >> versions of DrGeo.
>>>> >>
>>>> >> I invite other group interested to see DrGeo on Sugar, to compiled and
>>>> >> test a SqueakVM with the latest Sugar version. Idealy one should use the
>>>> >> COG Squeak VM coming with JITer and extend it to support the --sugar
>>>> >> application flags.
>>>> >> The Squeak VM coming with Sugar is an antiquity and slow horse anyway.
>>>> >>
>>>> >> Hilaire
>>>> >>
>>>> >> --
>>>> >> Dr. Geo -- http://www.drgeo.eu



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

The trace is not enlightening.

I'll take a shot in the dark:

I vaguely remember the XO-1's AMD Geode processor lacks some features that 
other x86 CPUs have. Do I remember correctly? If that is so, could you try 
compiling the VM in i386 compatibility mode? I don't recall how to do that, 
it's been too long ago ...

- Bert -

On 19.05.2012, at 23:01, Ariel Calzada wrote:

> Hi Bert!
> 
> Yes I compiled 4.4.7 and this doesn't work with drgeo.image, i tested with 
> pharo 1.3 image and it worked. Logs attached.
> 
> Regards,
> Ariel Calzada
> Activity Central
> 
> On 05/19/2012 03:57 PM, Bert Freudenberg wrote:
>> 
>> Hi Ariel,
>> 
>> there are messages missing from this thread. I did not see the message with 
>> your trace attachments.
>> 
>> But, are you saying you compiled the 4.4.7 Squeak VM on an old Fedora and it 
>> still does not work with DrGeo on an XO-1?
>> 
>> - Bert -
>> 
>> On 19.05.2012, at 21:47, Ariel Calzada wrote:
>> 
>>> Hi!
>>> 
>>> I downloaded it pharo image from 
>>> http://www.pharo-project.org/pharo-download/release-1-4, and got the same 
>>> error message. Is there any other test that i can do in order to fix the 
>>> error?.
>>> 
>>> Regards,
>>> Ariel Calzada
>>> Activity Central
>>> 
>>> 2012/5/19 Hilaire Fernandes 
>>> This VM was used with previous version of DrGeo.
>>> Is the problem related to the latest stable Sugar and the VM and XO-1?
>>> I tested DrGeo 11.08 and it worked with this identical set up.
>>> So It could be related to the Pharo image I used, or all related together.
>>> It is not easy to track the exact problem and it may take time.
>>> 
>>> One things to do could be to test latest, virgin, Pharo image 1.4 with
>>> this same image., so it could clarify the problem
>>> 
>>> Hilaire
>>> 
>>> 
>>> 
>>> On 19/05/2012 20:10, Ariel Calzada wrote:
>>> > Hi!
>>> >
>>> > We have made the following tests for XO 1.0:
>>> >
>>> > -- Run squeak binary  strace ./squeak drgeo.image ( Attachment:
>>> > strace-binary.txt )
>>> > -- Run squeak compiled  strace ./squeak drgeo.image ( Attachment:
>>> > strace-src.txt )
>>> >
>>> > Both tests were not successful we got segmentation fault errors, we had
>>> > review the strace logs but we haven't found why this happen.
>>> >
>>> > I hope this helps.
>>> >
>>> > Regards,
>>> > Ariel Calzada
>>> > Activity Central
>>> >
>>> >
>>> > 2012/5/16 Hilaire Fernandes 
>>> >
>>> >> It looks like the SqueakVM I compiled for DrGeo  does not work with X0-1
>>> >> last Sugar system, but ok with XO-1.5 last Sugar system.
>>> >>
>>> >> It will cost me too much to prepare a new VM, I am busy with tablet
>>> >> versions of DrGeo.
>>> >>
>>> >> I invite other group interested to see DrGeo on Sugar, to compiled and
>>> >> test a SqueakVM with the latest Sugar version. Idealy one should use the
>>> >> COG Squeak VM coming with JITer and extend it to support the --sugar
>>> >> application flags.
>>> >> The Squeak VM coming with Sugar is an antiquity and slow horse anyway.
>>> >>
>>> >> Hilaire
>>> >>
>>> >> --
>>> >> Dr. Geo -- http://www.drgeo.eu
>>> >>
>>> >> ___
>>> >> Sugar-devel mailing list
>>> >> Sugar-devel@lists.sugarlabs.org
>>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>>> >>
>>> 
>>> 
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> 
> 
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

Hi Ariel,

there are messages missing from this thread. I did not see the message with 
your trace attachments.

But, are you saying you compiled the 4.4.7 Squeak VM on an old Fedora and it 
still does not work with DrGeo on an XO-1?

- Bert -

On 19.05.2012, at 21:47, Ariel Calzada wrote:

> Hi!
> 
> I downloaded it pharo image from 
> http://www.pharo-project.org/pharo-download/release-1-4, and got the same 
> error message. Is there any other test that i can do in order to fix the 
> error?.
> 
> Regards,
> Ariel Calzada
> Activity Central
> 
> 2012/5/19 Hilaire Fernandes 
> This VM was used with previous version of DrGeo.
> Is the problem related to the latest stable Sugar and the VM and XO-1?
> I tested DrGeo 11.08 and it worked with this identical set up.
> So It could be related to the Pharo image I used, or all related together.
> It is not easy to track the exact problem and it may take time.
> 
> One things to do could be to test latest, virgin, Pharo image 1.4 with
> this same image., so it could clarify the problem
> 
> Hilaire
> 
> 
> 
> On 19/05/2012 20:10, Ariel Calzada wrote:
> > Hi!
> >
> > We have made the following tests for XO 1.0:
> >
> > -- Run squeak binary  strace ./squeak drgeo.image ( Attachment:
> > strace-binary.txt )
> > -- Run squeak compiled  strace ./squeak drgeo.image ( Attachment:
> > strace-src.txt )
> >
> > Both tests were not successful we got segmentation fault errors, we had
> > review the strace logs but we haven't found why this happen.
> >
> > I hope this helps.
> >
> > Regards,
> > Ariel Calzada
> > Activity Central
> >
> >
> > 2012/5/16 Hilaire Fernandes 
> >
> >> It looks like the SqueakVM I compiled for DrGeo  does not work with X0-1
> >> last Sugar system, but ok with XO-1.5 last Sugar system.
> >>
> >> It will cost me too much to prepare a new VM, I am busy with tablet
> >> versions of DrGeo.
> >>
> >> I invite other group interested to see DrGeo on Sugar, to compiled and
> >> test a SqueakVM with the latest Sugar version. Idealy one should use the
> >> COG Squeak VM coming with JITer and extend it to support the --sugar
> >> application flags.
> >> The Squeak VM coming with Sugar is an antiquity and slow horse anyway.
> >>
> >> Hilaire
> >>
> >> --
> >> Dr. Geo -- http://www.drgeo.eu
> >>
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >>
> 
> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [support-gang] Clarifications: Help package a 3D activity

[Bert Freudenberg]

On 17.05.2012, at 03:36, Mikus Grinbergs wrote:

> This is not going to work on ARM; the target was said to be XO-1
>> Feedback for  to ensure that it does something
>> sensible on ARM, like "sorry, your computer is too new for this
>> activity"
> 
> On 05/16/2012 07:42 PM, James Cameron wrote:
>> I think Sugar leans toward architecture independence in the .xo files,
>> but it's something that could be raised again with Sugar Labs.
> 
> It should be feasible to "test before you run" -- but this Activity includes 
> a binary, and as far as I know ARM machine instructions are not the same as 
> x86 machine instructions -- and including TWO binaries (one for each 
> architecture) leads to ".xo bloat".
> 
> And, from my limited knowledge (I haven't kept up), the design for Activities 
> does NOT include a way for Activities to __test__ whether dependent RPMs are 
> provided by the runtime environment.  Dependencies have traditionally been 
> addressed by __including__ them in the .xo package -- but that just means 
> *more* architecture-dependent files.
> 
> mikus


Executables tend to be small compared to data files. For users, a "fat" bundle 
containing multiple architectures is arguably simplest. You could use something 
like this:

ARCH=`uname -m`
BIN="$SUGAR_BUNDLE_PATH/bin-$ARCH"
exec $BIN/myexecutable

... and have both a "bin-i686" and "bin-arm7vl" directory (and lib dirs if 
needed).

As an example, there is a DrGeo activity bundle that supports both 
architectures (last time I looked, the ARM part included way too many files, 
but it appears to work):
http://people.sugarlabs.org/rafael/UY/
(the proper way here would have been installing a newer Squeak VM in the 
system, but bundling it inside the activity is a good short-term workaround).


- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel