Hi, bert.
While I am still working on stabilizing runtime-translation stuff to make smooth to integrate add-on applications with base Etoys, I hit fundamental question: how to distribute and install addon application with translation.
We need to do following that seem difficult on OLPC if I understand correctly: - EToys use installed MOs for translation, so additional MOs for the apps need to be installed onto file system. - Additional domains/MOs need to be registered by API call, and that registration is stored in image in current implementation.
We have had great apps for Squeak, but.. - the last version of DrGeoII is packaged as SAR. It is possible to execute almost anything in preamble, but MOs installation seems impossible in Rainbow-enabled environment. - the last version of BotInc is packaged as project. How to package MOs in tt? - For both case, can domain registration be stored in Journal and restored ? it is easy for squeakland-OLPC user to save image...
So only way to provide translation for apps is that preload apps and rename image and package them as RPM. I would like to hear your thought.
(I understand we have similar issue with additional font...)
/Korakurider -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/
On Nov 11, 2007, at 2:22 , korakurider@yahoo.co.jp wrote:
Hi, bert.
While I am still working on stabilizing runtime-translation stuff to make smooth to integrate add-on applications with base Etoys, I hit fundamental question: how to distribute and install addon application with translation.
An important question, and I have more ideas than time to implement :/
We need to do following that seem difficult on OLPC if I understand correctly:
- EToys use installed MOs for translation, so additional MOs for the apps need to be installed onto file system.
They can be put in the app's .xo bundle.
- Additional domains/MOs need to be registered by API call, and that registration is stored in image in current implementation.
It would be added by the code in the bundle.
We have had great apps for Squeak, but..
- the last version of DrGeoII is packaged as SAR. It is possible to execute almost anything in preamble, but MOs installation seems impossible in Rainbow-enabled environment.
A SAR may or may not be the best packaging. It could actually extract a .mo to the default directory, so we would just have to support an additional path for .mo files.
- the last version of BotInc is packaged as project. How to
package MOs in tt?
I guess it would have to be distributed in the same .xo (or .xol?) bundle as the project. Adding the .mo to the project file itself would also be possible (it's just a zip file), making the projects self-contained. Not sure that is advisable though.
- For both case, can domain registration be stored in Journal and
restored ? it is easy for squeakland-OLPC user to save image...
No, it is not easy to save the image. If we make it easy, we would also have to provide an equally easy way of restoring the default image.
So only way to provide translation for apps is that preload apps and rename image and package them as RPM. I would like to hear your thought.
No, apps must be packaged as .xo files. We will just have to find a way to support this. SImilar to what I did with the DiceWars xo bundle a while ago.
(I understand we have similar issue with additional font...)
The font can simply be saved in the default directory, just as we do now I think.
- Bert -
Bert Freudenberg bert@freudenbergs.de wrote：
A SAR may or may not be the best packaging. It could actually extract a .mo to the default directory, so we would just have to support an additional path for .mo files.
Current gettext emulation stuff can support search path list for MO and even dynamic registration of additional path. so it is easy to add the default path (that is sand box of rainbow, right?) to search list. Difficult part is that the registration have to be restored also.
(I think we need to start write down "the good practice for app on OLPC Etoys" to document the rule / convention. This discussion is the first step.)
So only way to provide translation for apps is that preload apps and rename image and package them as RPM. I would like to hear your thought.
No, apps must be packaged as .xo files. We will just have to find a way to support this. SImilar to what I did with the DiceWars xo bundle a while ago.
As I have been working without Sugar/emulation environment, I haven' t figure out what is the hurdle to support it...
(I understand we have similar issue with additional font...)
The font can simply be saved in the default directory, just as we do now I think.
No, I was refering about not saving font file, but registration of additional font to image and its restoration, as you and Luke are discussing in http://dev.laptop.org/ticket/4604
/Korakurider -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/
On Nov 11, 2007, at 15:23 , korakurider@yahoo.co.jp wrote:
Bert Freudenberg bert@freudenbergs.de wrote：
A SAR may or may not be the best packaging. It could actually extract a .mo to the default directory, so we would just have to support an additional path for .mo files.
Current gettext emulation stuff can support search path listfor MO and even dynamic registration of additional path. so it is easy to add the default path (that is sand box of rainbow, right?) to search list. Difficult part is that the registration have to be restored also.
(I think we need to start write down "the good practice for app on OLPC Etoys" to document the rule / convention. This discussion is the first step.)
Yes ... people will have to get familiar with Sugar I fear. We can't abstract away everything.
So only way to provide translation for apps is that preload apps and rename image and package them as RPM. I would like to hear your thought.
No, apps must be packaged as .xo files. We will just have to find a way to support this. SImilar to what I did with the DiceWars xo bundle a while ago.
As I have been working without Sugar/emulation environment, Ihaven' t figure out what is the hurdle to support it...
Once OLPC has some XOs to spare we should definitely get you one. Thanks for doing all this work without even being able to test directly!
When I find a bit of spare time I will look into Sugar in an emulator again. It's too bad that not even the stable build is working :(
(I understand we have similar issue with additional font...)
The font can simply be saved in the default directory, just as we do now I think.
No, I was refering about not saving font file, but registration ofadditional font to image and its restoration, as you and Luke are discussing in http://dev.laptop.org/ticket/4604
Ah. That problem will be solved when we switch to Pango - we do not have to import the fonts anymore. Not for Update.1, unfortunately.
- Bert -
2007/11/11, korakurider@yahoo.co.jp korakurider@yahoo.co.jp:
I hit fundamental question: how to distribute and install addon application with translation.
Yes, you got a point. Which features do we need ?
- a Squeak application should be installable at runtime, without modifying the image - a project using a loaded application should re-load the application - application translation should be reloadable at runtime aswel.
I have tested loading DrGeo SAR into the OLPC. In my opinion it is too slow and I am afraid teachers and kids will run away. Imagine a situation where a kid need to review sever interactive geometric sketch. We will have an acceptability problem there.
I have heard about ImageSegment, I only got an overall understanding about it but I have the felling it may be the fastest solution.
Hilaire
Hilaire Fernandes wrote:
2007/11/11, korakurider@yahoo.co.jp korakurider@yahoo.co.jp:
I hit fundamental question: how to distribute and install addon application with translation.
Yes, you got a point. Which features do we need ?
- a Squeak application should be installable at runtime, without
modifying the image
- a project using a loaded application should re-load the application
- application translation should be reloadable at runtime aswel.
I have tested loading DrGeo SAR into the OLPC. In my opinion it is too slow and I am afraid teachers and kids will run away. Imagine a situation where a kid need to review sever interactive geometric sketch. We will have an acceptability problem there.
I have heard about ImageSegment, I only got an overall understanding about it but I have the felling it may be the fastest solution.
Projects are saved in image segments, but code changes are not captured in the segment so those are filed in from a changeset. This is quite slow.
Karl
On Nov 14, 2007, at 20:44 , karl wrote:
Hilaire Fernandes wrote:
2007/11/11, korakurider@yahoo.co.jp korakurider@yahoo.co.jp:
I hit fundamental question: how to distribute and install addon application with translation.
Yes, you got a point. Which features do we need ?
- a Squeak application should be installable at runtime, without
modifying the image
- a project using a loaded application should re-load the application
- application translation should be reloadable at runtime aswel.
I have tested loading DrGeo SAR into the OLPC. In my opinion it is too slow and I am afraid teachers and kids will run away. Imagine a situation where a kid need to review sever interactive geometric sketch. We will have an acceptability problem there.
I have heard about ImageSegment, I only got an overall understanding about it but I have the felling it may be the fastest solution.
Projects are saved in image segments, but code changes are not captured in the segment so those are filed in from a changeset. This is quite slow.
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
- Bert -
Folks, QuickGuides is a flap in Etoys that contains help on many topics. There are 54 Guides, and they were written by Kathleen Harness. We have recently changed how the Index Guide works. It is the first guide to show in the flap, and allows you to get to all the other Guides. You get Guides flap by clicking on the [?] icon that is left-most in the gray bar across the top of the screen. You may get an error window when opening guides. This email tells you how to get the latest guides and avoid the error.
If you get Etoys from the current http://etoys.laptop.org/src/etoys-image-and-pr.zip then QuickGuides will work fine. You can stop reading here.
If you have a development image that you are working in, here is how to upgrade it.
1) Fetch updates in your image.
2) Mount a folder using webDav: On a Mac: the Go menu, Connect to server... On Windows: Go to My Network Places, and click on Add Network Place at the top of the left sidebar On Linux: (I'm sure you already know how to mount a directory on a server!)
enter http://etoys.laptop.org:80/svn/trunk/etoys/ When the folder show up, drag the entire QuickGuides folder to the place where you keep your OLPC-Squeak.image.
3) In your web browser, go to http://tinlizzie.org/olpc/ Right-click on the file "index.pr" and choose "Save as..." Save it in your QuickGuides folder.
Since your own image did not go through the OLPC release process, you need to have the extra file "index.pr" in the QuickGuides folder.
Now you can start etoys and click on the [?] help icon.
--Ted.
I really like the tutorials. You cover a lot of topics that are essential to etoys. Keep them comming :-)
I have a suggestion: change the 'Jump to...' to look like other menu buttons and add a home button (could look like a little house) to get to the index.
Karl
Ted Kaehler wrote:
Folks, QuickGuides is a flap in Etoys that contains help on many topics. There are 54 Guides, and they were written by Kathleen Harness. We have recently changed how the Index Guide works. It is the first guide to show in the flap, and allows you to get to all the other Guides. You get Guides flap by clicking on the [?] icon that is left-most in the gray bar across the top of the screen. You may get an error window when opening guides. This email tells you how to get the latest guides and avoid the error.
If you get Etoys from the current http://etoys.laptop.org/src/etoys-image-and-pr.zip then QuickGuides will work fine. You can stop reading here.
If you have a development image that you are working in, here is how to upgrade it.
Fetch updates in your image.
Mount a folder using webDav:
On a Mac: the Go menu, Connect to server... On Windows: Go to My Network Places, and click on Add Network Place at the top of the left sidebar On Linux: (I'm sure you already know how to mount a directory on a server!)
enter http://etoys.laptop.org:80/svn/trunk/etoys/ When the folder show up, drag the entire QuickGuides folder to the place where you keep your OLPC-Squeak.image.
- In your web browser, go to http://tinlizzie.org/olpc/
Right-click on the file "index.pr" and choose "Save as..." Save it in your QuickGuides folder.
Since your own image did not go through the OLPC release process, you need to have the extra file "index.pr" in the QuickGuides folder.
Now you can start etoys and click on the [?] help icon.
--Ted.
Ted,
actually the index.pr file is already in
http://etoys.laptop.org:80/svn/trunk/etoys/QuickGuides/
If it was not, we would have to put it there, since it is essential for developers. We really want to have all necessary things in one place. As time permits we need to put our dev image into that svn repository, too.
- Bert -
On Nov 15, 2007, at 8:32 , Ted Kaehler wrote:
Folks, QuickGuides is a flap in Etoys that contains help on many topics. There are 54 Guides, and they were written by Kathleen Harness. We have recently changed how the Index Guide works. It is the first guide to show in the flap, and allows you to get to all the other Guides. You get Guides flap by clicking on the [?] icon that is left-most in the gray bar across the top of the screen. You may get an error window when opening guides. This email tells you how to get the latest guides and avoid the error.
If you get Etoys from the current http://etoys.laptop.org/src/etoys-image-and-pr.zip then QuickGuides will work fine. You can stop reading here.
If you have a development image that you are working in, here is how to upgrade it.
Fetch updates in your image.
Mount a folder using webDav:
On a Mac: the Go menu, Connect to server... On Windows: Go to My Network Places, and click on Add Network Place at the top of the left sidebar On Linux: (I'm sure you already know how to mount a directory on a server!)
enter http://etoys.laptop.org:80/svn/trunk/etoys/ When the folder show up, drag the entire QuickGuides folder to the place where you keep your OLPC-Squeak.image.
- In your web browser, go to http://tinlizzie.org/olpc/
Right-click on the file "index.pr" and choose "Save as..." Save it in your QuickGuides folder.
Since your own image did not go through the OLPC release process, you need to have the extra file "index.pr" in the QuickGuides folder.
Now you can start etoys and click on the [?] help icon.
--Ted.
-- Ted Kaehler http://www.squeakland.org/~ted/ Job applicant: "I have a special talent. I can read people's minds." Interviewer: "Then I don't need to tell you why we can't use you..." from The War Magician by David Fisher. _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Folks, Bert is right! You only need to do steps 1 and 2 below. --Ted.
Folks, QuickGuides is a flap in Etoys that contains help on many topics. There are 54 Guides, and they were written by Kathleen Harness. We have recently changed how the Index Guide works. It is the first guide to show in the flap, and allows you to get to all the other Guides. You get Guides flap by clicking on the [?] icon that is left-most in the gray bar across the top of the screen. You may get an error window when opening guides. This email tells you how to get the latest guides and avoid the error.
If you get Etoys from the current http://etoys.laptop.org/src/etoys-image-and-pr.zip then QuickGuides will work fine. You can stop reading here.
If you have a development image that you are working in, here is how to upgrade it.
Fetch updates in your image.
Mount a folder using webDav:
On a Mac: the Go menu, Connect to server... On Windows: Go to My Network Places, and click on Add Network Place at the top of the left sidebar On Linux: (I'm sure you already know how to mount a directory on a server!)
enter http://etoys.laptop.org:80/svn/trunk/etoys/ When the folder show up, drag the entire QuickGuides folder to the place where you keep your OLPC-Squeak.image.
(You are ready to start etoys. Step 3 is not necessary.)
Now you can start etoys and click on the [?] help icon.
--Ted.
Now I remember Yoshiki wrote several weak ago about another possibility.
To just ship alternative Squeak/Smalltalk application like DrGeo in their own .image. What will be required to do that ? Starting from the standard etoys image? This solution will solve the problem about loading project file with existing geometric diagram.
Hilaire
2007/11/14, Bert Freudenberg bert@freudenbergs.de:
On Nov 14, 2007, at 20:44 , karl wrote:
Hilaire Fernandes wrote:
2007/11/11, korakurider@yahoo.co.jp korakurider@yahoo.co.jp:
I hit fundamental question: how to distribute and install addon application with translation.
Yes, you got a point. Which features do we need ?
- a Squeak application should be installable at runtime, without
modifying the image
- a project using a loaded application should re-load the application
- application translation should be reloadable at runtime aswel.
I have tested loading DrGeo SAR into the OLPC. In my opinion it is too slow and I am afraid teachers and kids will run away. Imagine a situation where a kid need to review sever interactive geometric sketch. We will have an acceptability problem there.
I have heard about ImageSegment, I only got an overall understanding about it but I have the felling it may be the fastest solution.
Projects are saved in image segments, but code changes are not captured in the segment so those are filed in from a changeset. This is quite slow.
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
You would need to hack the startup script and include the image in your .xo. I did that for the OLE Nepal image:
http://lists.laptop.org/pipermail/etoys/2007-November/001394.html
However, it would be extremely inefficient space-wise to do that as 99% of the image would be identical to the etoys image and you're simply wasting 15 MB of space.
- Bert -
On Nov 16, 2007, at 20:31 , Hilaire Fernandes wrote:
Now I remember Yoshiki wrote several weak ago about another possibility.
To just ship alternative Squeak/Smalltalk application like DrGeo in their own .image. What will be required to do that ? Starting from the standard etoys image? This solution will solve the problem about loading project file with existing geometric diagram.
Hilaire
2007/11/14, Bert Freudenberg bert@freudenbergs.de:
On Nov 14, 2007, at 20:44 , karl wrote:
Hilaire Fernandes wrote:
2007/11/11, korakurider@yahoo.co.jp korakurider@yahoo.co.jp:
I hit fundamental question: how to distribute and install addon application with translation.
Yes, you got a point. Which features do we need ?
- a Squeak application should be installable at runtime, without
modifying the image
- a project using a loaded application should re-load the
application
- application translation should be reloadable at runtime aswel.
I have tested loading DrGeo SAR into the OLPC. In my opinion it is too slow and I am afraid teachers and kids will run away. Imagine a situation where a kid need to review sever interactive geometric sketch. We will have an acceptability problem there.
I have heard about ImageSegment, I only got an overall understanding about it but I have the felling it may be the fastest solution.
Projects are saved in image segments, but code changes are not captured in the segment so those are filed in from a changeset. This is quite slow.
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
-- http://blog.ofset.org/hilaire Smalltalkers do: [:it | All with: Class, (And love: it)]
Bert Freudenberg wrote:
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
I have looked into this a little. There is a framework for creating conversion methods in the image but it is broken.
To test make a new project, add a new morpic class, open the morph in the project and publish. Restart Squeak and load the project. You will be prompted to type in a new class name, a debugger pops up, and a Inspector. Once you get past that you will see the project view on the desktop but you will also enter the emergency debugger :-(
I hope once the issues are fixed we can just file out the conversion files and include them in the projects instead of the whole change sets and projects will load faster. Conversion methods can also be in the image.
Karl
Karl wrote:
Bert Freudenberg wrote:
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
I have looked into this a little. There is a framework for creating conversion methods in the image but it is broken.
To test make a new project, add a new morpic class, open the morph in the project and publish. Restart Squeak and load the project. You will be prompted to type in a new class name, a debugger pops up, and a Inspector. Once you get past that you will see the project view on the desktop but you will also enter the emergency debugger :-(
I hope once the issues are fixed we can just file out the conversion files and include them in the projects instead of the whole change sets and projects will load faster. Conversion methods can also be in the image.
Karl ______
Forget previous mail. What is needed is a change set with just the class definition for every new class in your project. The big catch is it seems _every_ object needs to be referenced in the project or it will not be accessible. I just tested with DrGeo, I made a change set with just the class definition, and could open a project but all the functionality was missing :-(
Karl
On Nov 20, 2007, at 18:31 , Karl wrote:
Karl wrote:
Bert Freudenberg wrote:
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
I have looked into this a little. There is a framework for creating conversion methods in the image but it is broken.
To test make a new project, add a new morpic class, open the morph in the project and publish. Restart Squeak and load the project. You will be prompted to type in a new class name, a debugger pops up, and a Inspector. Once you get past that you will see the project view on the desktop but you will also enter the emergency debugger :-(
I hope once the issues are fixed we can just file out the conversion files and include them in the projects instead of the whole change sets and projects will load faster. Conversion methods can also be in the image.
Karl ______
Forget previous mail. What is needed is a change set with just the class definition for every new class in your project. The big catch is it seems _every_ object needs to be referenced in the project or it will not be accessible. I just tested with DrGeo, I made a change set with just the class definition, and could open a project but all the functionality was missing :-(
Classes and methods except for Player subclasses are not included in the project image segment currently.
- Bert -
Moreover, in case a DrGeo project file is prepared by the teacher for his students, only a subset of DrGeo classes may be use, but the teacher could request the students to construct geometric objects based on other DrGeo classes, not used in the initial .pr file. Can it be a problem?
Hilaire
2007/11/20, Bert Freudenberg bert@freudenbergs.de:
On Nov 20, 2007, at 18:31 , Karl wrote:
Karl wrote:
Bert Freudenberg wrote:
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
I have looked into this a little. There is a framework for creating conversion methods in the image but it is broken.
To test make a new project, add a new morpic class, open the morph in the project and publish. Restart Squeak and load the project. You will be prompted to type in a new class name, a debugger pops up, and a Inspector. Once you get past that you will see the project view on the desktop but you will also enter the emergency debugger :-(
I hope once the issues are fixed we can just file out the conversion files and include them in the projects instead of the whole change sets and projects will load faster. Conversion methods can also be in the image.
Karl ______
Forget previous mail. What is needed is a change set with just the class definition for every new class in your project. The big catch is it seems _every_ object needs to be referenced in the project or it will not be accessible. I just tested with DrGeo, I made a change set with just the class definition, and could open a project but all the functionality was missing :-(
Classes and methods except for Player subclasses are not included in the project image segment currently.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Hilaire Fernandes wrote:
Moreover, in case a DrGeo project file is prepared by the teacher for his students, only a subset of DrGeo classes may be use, but the teacher could request the students to construct geometric objects based on other DrGeo classes, not used in the initial .pr file. Can it be a problem?
As long as the full change set is in the image or attached to the project, it's not a problem.
The problem is that change set loading is slow on a big project like DrGeo.
If the project could include compiled methods and classes loading would be much faster. Karl
Hilaire
2007/11/20, Bert Freudenberg bert@freudenbergs.de:
On Nov 20, 2007, at 18:31 , Karl wrote:
Karl wrote:
Bert Freudenberg wrote:
Loading an ImageSegment is indeed extremely fast. Even classes and compiled methods can be included in a segment. The problem is that after loading the segment, references ("outpointers") have to be fixed up - for example, all symbols must be made to point to the symbol instance in the image, otherwise you would have duplicate symbols. And we accumulated a lot of cruft over the years that is performed on project load time - fixing up fonts, migrating instances to new class layout etc. Working this out would be very valuable.
I have looked into this a little. There is a framework for creating conversion methods in the image but it is broken.
To test make a new project, add a new morpic class, open the morph in the project and publish. Restart Squeak and load the project. You will be prompted to type in a new class name, a debugger pops up, and a Inspector. Once you get past that you will see the project view on the desktop but you will also enter the emergency debugger :-(
I hope once the issues are fixed we can just file out the conversion files and include them in the projects instead of the whole change sets and projects will load faster. Conversion methods can also be in the image.
Karl ______
Forget previous mail. What is needed is a change set with just the class definition for every new class in your project. The big catch is it seems _every_ object needs to be referenced in the project or it will not be accessible. I just tested with DrGeo, I made a change set with just the class definition, and could open a project but all the functionality was missing :-(
Classes and methods except for Player subclasses are not included in the project image segment currently.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
--- Hilaire Fernandes hilaire@ofset.org wrote:
Moreover, in case a DrGeo project file is prepared by the teacher for his students, only a subset of DrGeo classes may be use, but the teacher could request the students to construct geometric objects based on other DrGeo classes, not used in the initial .pr file. Can it be a problem?
I think it wouldn't be great for each project to hold additional classes even loading is fast, because of the problems Hilaire described.
I am imagining some off-image package like DLL ,containing classes and compiled methods that are addition to base image. Activity bundle includes the off-image package that the bundle needs. First, the packages are dynamically loaded when activity starts. Next, project of the activity is loaded.
(This is just a idea without how to implement :)
/Korakurider
-------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/
Bert Freudenberg wrote:
Classes and methods except for Player subclasses are not included in the project image segment currently.
- Bert -
I see that SISSDictionaryForScanning has a forceAdd: method that we could give the classes in the current change set. What do you think?
Karl
Classes and methods except for Player subclasses are not included in the project image segment currently.
I see that SISSDictionaryForScanning has a forceAdd: method that we could give the classes in the current change set. What do you think?
If I'm not mistaken, Bert was refering to #storeOnServerWithNoInteraction method with conventional (i.e., non-SISS) format.
forceAdd: is a SISS version of DiskProxy and itself doesn't include the methods and code.
I fantasized an idea where methods in projects are 'half-compiled'. It would be a compact form of parse tree with holes, and the holes would be quickly filled with the global Associations and other literals upon loading...
-- Yoshiki
Yoshiki Ohshima wrote:
Classes and methods except for Player subclasses are not included in the project image segment currently.
I see that SISSDictionaryForScanning has a forceAdd: method that we could give the classes in the current change set. What do you think?
If I'm not mistaken, Bert was refering to #storeOnServerWithNoInteraction method with conventional (i.e., non-SISS) format.
forceAdd: is a SISS version of DiskProxy and itself doesn't include the methods and code.
I fantasized an idea where methods in projects are 'half-compiled'. It would be a compact form of parse tree with holes, and the holes would be quickly filled with the global Associations and other literals upon loading...
I did a hack like this:
PasteUpMorph>>sissScanObjectsAsEtoysProject
| dict ret classes | dict _ SISSDictionaryForScanning new initialize. self cleanUpReferences. dict boundaryObjects add: Utilities scrapsBook. Utilities scrapsBook pages do: [:p | dict boundaryObjects add: p]. worldState ifNotNil: [self hands do: [:h | dict boundaryObjects add: h]]. dict _ ChangeSet current changedClasses. ret _ dict sissScanObjectsFrom: self. ^ ret.
And it seems the project saves the classes in the image segment as the size is much bigger that without the hack. On project load, class methodDictionaries are restored once class definitions are filed in, but the method bodies are lost.
Karl
And it seems the project saves the classes in the image segment as the size is much bigger that without the hack. On project load, class methodDictionaries are restored once class definitions are filed in, but the method bodies are lost.
If we respect the spirit of SISS, the code should be store as source text, or S-expression that corresponds to the parse tree of text. Of course, we are missing the serializer and de-serializer for normal Smalltalk code at this point...
-- Yoshiki
Yoshiki Ohshima wrote:
Classes and methods except for Player subclasses are not included in the project image segment currently.
I see that SISSDictionaryForScanning has a forceAdd: method that we could give the classes in the current change set. What do you think?
If I'm not mistaken, Bert was refering to #storeOnServerWithNoInteraction method with conventional (i.e., non-SISS) format.
forceAdd: is a SISS version of DiskProxy and itself doesn't include the methods and code.
I fantasized an idea where methods in projects are 'half-compiled'. It would be a compact form of parse tree with holes, and the holes would be quickly filled with the global Associations and other literals upon loading...
I tested using CodeLoader with DrGeo but it seems load times are about the same as with the regular project saving with less control over included changes :-(
CodeLoader exportCodeSegment: 'tester.extSeg' classes: ChangeSet current changedClasses keepSource: false
Karl
I tested using CodeLoader with DrGeo but it seems load times are about the same as with the regular project saving with less control over included changes :-(
CodeLoader exportCodeSegment: 'tester.extSeg' classes: ChangeSet current changedClasses keepSource: false
CodeLoader still uses textual code and you need to parse it upon loading, right?
-- Yoshiki
Yoshiki Ohshima wrote:
I tested using CodeLoader with DrGeo but it seems load times are about the same as with the regular project saving with less control over included changes :-(
CodeLoader exportCodeSegment: 'tester.extSeg' classes: ChangeSet current changedClasses keepSource: false
CodeLoader still uses textual code and you need to parse it upon loading, right?
CodeLoader uses ImageSegment>>copyFromRootsForExport: . The scanning for classes is not optimal as it does not allow compact classes, which you can have in change sets.
I have not found any way of loading segments with outpointers without code filein/ recompilation.
Karl
Yoshiki Ohshima wrote:
I tested using CodeLoader with DrGeo but it seems load times are about the same as with the regular project saving with less control over included changes :-(
CodeLoader exportCodeSegment: 'tester.extSeg' classes: ChangeSet current changedClasses keepSource: false
CodeLoader still uses textual code and you need to parse it upon loading, right?
There is a method in ImageSegment that looks promising:
ImageSegment>>scanFrom: aStream "Move source code from a fileIn to the changes file for classes in an ImageSegment. Do not compile the methods. They already came in via the image segment. After the ImageSegment in the file, !ImageSegment new! captures control, and scanFrom: is called." | val chunk |
[aStream atEnd] whileFalse: [aStream skipSeparators. val _ (aStream peekFor: $!) ifTrue: ["Move (aStream nextChunk), find the method or class comment, and install the file location bytes" (Compiler evaluate: aStream nextChunk logged: false) scanFromNoCompile: aStream forSegment: self] ifFalse: [chunk _ aStream nextChunk. aStream checkForPreamble: chunk. Compiler evaluate: chunk logged: true]. aStream skipStyleChunk]. "regular fileIn will close the file" ^ val
I'm not sure the method is actually called from anywhere. I put in a 'self halt' but no luck... Anyway the method seems to hint at a way to get the outpointers in to the image with no recompilation.
Karl
Hello to all. I would like to ask if there is utf8 support in the Squeak VM currently. I know that in the past only 8-bit encoding was supported by the virtual machine. Is it the same nowadays? I am considering the addition of the greek language which requires utf8 to be supported by the VM.
On Nov 29, 2007, at 10:23 , birbilis wrote:
Hello to all. I would like to ask if there is utf8 support in the Squeak VM currently. I know that in the past only 8-bit encoding was supported by the virtual machine. Is it the same nowadays? I am considering the addition of the greek language which requires utf8 to be supported by the VM.
UTF-8 is supported. The "etoys" script now runs the VM using the "- encoding UTF-8" option.
- Bert -
Hello to all. I would like to ask if there is utf8 support in the Squeak VM currently. I know that in the past only 8-bit encoding was supported by the virtual machine. Is it the same nowadays? I am considering the addition of the greek language which requires utf8 to be supported by the VM.
UTF-8 is supported. The "etoys" script now runs the VM using the "- encoding UTF-8" option.
Nice...birbilis, why don't you try to open the image from "ellak" inside the OLPC having the new UTF-8 enabled VM and see how it goes?
http://www.ellak.gr/index.php?option=com_openwiki&Itemid=103&id=ella..., i don't remember if a have removed the switches thatdifferentiate Windows and Unix behaviour, but it's worth trying... Ifkeyboard input works correctly, then we are a big step forward...Christos
Στις Πεμ 29 Νοε 2007, ο/η Chris Petsos έγραψε:
Hello to all. I would like to ask if there is utf8 support in the Squeak VM currently. I know that in the past only 8-bit encoding was supported by the virtual machine. Is it the same nowadays? I am considering the addition of the greek language which requires utf8 to be supported by the VM.
UTF-8 is supported. The "etoys" script now runs the VM using the "- encoding UTF-8" option.
Nice...birbilis, why don't you try to open the image from "ellak" inside the OLPC having the new UTF-8 enabled VM and see how it goes?
http://www.ellak.gr/index.php?option=com_openwiki&Itemid=103&id=ella... etoys_greek_supportCurrently, i don't remember if a have removed the switches thatdifferentiate Windows and Unix behaviour, but it's worth trying... Ifkeyboard input works correctly, then we are a big step forward...Christos
Tried that, but when i switch k/b layout to greek and try to insert text in e.g. a textbox area, i only get non-sense symbols as if the squeak environment does not recognize utf8 greek symbols. Greek fonts in the greeding message appear just fine which means that the fonts are there...
On Nov 29, 2007, at 12:20 , birbilis wrote:
Στις Πεμ 29 Νοε 2007, ο/η Chris Petsos έγραψε:
Hello to all. I would like to ask if there is utf8 support in the Squeak VM currently. I know that in the past only 8-bit encoding was supported by the virtual machine. Is it the same nowadays? I am considering the addition of the greek language which requires utf8 to be supported by the VM.
UTF-8 is supported. The "etoys" script now runs the VM using the "- encoding UTF-8" option.
Nice...birbilis, why don't you try to open the image from "ellak" inside the OLPC having the new UTF-8 enabled VM and see how it goes?
http://www.ellak.gr/index.php? option=com_openwiki&Itemid=103&id=ellak:olpc_ etoys_greek_supportCurrently, i don't remember if a have removed the switches thatdifferentiate Windows and Unix behaviour, but it's worth trying... Ifkeyboard input works correctly, then we are a big step forward...Christos
Tried that, but when i switch k/b layout to greek and try to insert text in e.g. a textbox area, i only get non-sense symbols as if the squeak environment does not recognize utf8 greek symbols. Greek fonts in the greeding message appear just fine which means that the fonts are there...
When I copy "ελληνική γλώσσα" from Firefox and paste this into Squeak under Linux (using OLPC image and VM), the first character is 16r3B5 which seems right (although, in my image it is displayed as "??????? ???????"). I can't copy a WideString out of Squeak, however.
And typing greek chars on the keyboard only works if running under Sugar. We have no better way to test if we actually have a new VM. I attached a CS that tries to do a better job - always use Unicode keyboard input, but fall back to MacRoman if the unicode char is 0. Let's see what Yoshiki thinks of this ...
- Bert -
http://www.ellak.gr/index.php?option=com_openwiki&Itemid=103&id=ella..., i don't remember if a have removed the switches thatdifferentiate Windows and Unix behaviour, but it's worth trying... Ifkeyboard input works correctly, then we are a big step forward...Christos
The OLPC branch should be better, Bert said that when he set the keyboard on XO to greek keyboard, normal character input works, but key strokes with modifier keys (like Alt-) reports a greek character with modifier bits, so when you would like to do Alt-b (for example) it comes as Alt-beta and Squeak's command key mapping cannot handle it.
The latest Windows VM (3.10) has better chance but may have the same issue.
Displaying Greek with TrueType... I dropped the ball long time ago, but now I'll try it to see what should be done.
-- Yoshiki
The OLPC branch should be better,
Yes, i agree on that...Really? Has anyone from the greek team tested the olpc image and VM? Since i was away for a while, it looks like now utf-8 input comes "out of the box" for eToys, so it doesn't seem to be needing any effort from our side.
Bert said that when he set the keyboard on XO to greek keyboard, normal character input works, but key strokes with modifier keys (like Alt-) reports a greek character with modifier bits, so when you would like to do Alt-b (for example) it comes as Alt-beta and Squeak's command key mapping cannot handle it.
Yes, that was the problem with multi-byte utf-8 characters. How can one map a unicode code-point to a shortcut since the app can react only to simple one-byte modidied characters. My workaround was a bit naive but can suffice if nothing else can be done. I had mapped all the greek unicode characters to their equivelant latin ones that squeak is expecting as a shortcut if a modifier key is pressed. So, every time the user presses alt+"beta" the charcode send is actually alt+"b" and the shortcut is executed correctly.. It is a job done inside the greek InpuInterpreter...
Chris.
Στις Παρ 30 Νοε 2007, ο/η Chris Petsos έγραψε:
The OLPC branch should be better,
Yes, i agree on that...Really? Has anyone from the greek team tested the olpc image and VM? Since i was away for a while, it looks like now utf-8 input comes "out of the box" for eToys, so it doesn't seem to be needing any effort from our side.
Bert said that when he set the keyboard on XO to greek keyboard, normal character input works, but key strokes with modifier keys (like Alt-) reports a greek character with modifier bits, so when you would like to do Alt-b (for example) it comes as Alt-beta and Squeak's command key mapping cannot handle it.
Yes, that was the problem with multi-byte utf-8 characters. How can one map a unicode code-point to a shortcut since the app can react only to simple one-byte modidied characters. My workaround was a bit naive but can suffice if nothing else can be done. I had mapped all the greek unicode characters to their equivelant latin ones that squeak is expecting as a shortcut if a modifier key is pressed. So, every time the user presses alt+"beta" the charcode send is actually alt+"b" and the shortcut is executed correctly.. It is a job done inside the greek InpuInterpreter...
Chris.
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
I upgrated to latest sugar-jbuild and i greek layout works in activities like abiword of konsole, but under etoys i only get ????? when i try to insert greek uft8 chars. So i guess the utf8 support of squeak does not work "out of the box" :(
On Dec 3, 2007, at 10:34 , birbilis wrote:
Στις Παρ 30 Νοε 2007, ο/η Chris Petsos έγραψε:
The OLPC branch should be better,
Yes, i agree on that...Really? Has anyone from the greek team tested the olpc image and VM? Since i was away for a while, it looks like now utf-8 input comes "out of the box" for eToys, so it doesn't seem to be needing any effort from our side.
Bert said that when he set the keyboard on XO to greek keyboard, normal character input works, but key strokes with modifier keys (like Alt-) reports a greek character with modifier bits, so when you would like to do Alt-b (for example) it comes as Alt-beta and Squeak's command key mapping cannot handle it.
Yes, that was the problem with multi-byte utf-8 characters. How can one map a unicode code-point to a shortcut since the app can react only to simple one-byte modidied characters. My workaround was a bit naive but can suffice if nothing else can be done. I had mapped all the greek unicode characters to their equivelant latin ones that squeak is expecting as a shortcut if a modifier key is pressed. So, every time the user presses alt +"beta" the charcode send is actually alt+"b" and the shortcut is executed correctly.. It is a job done inside the greek InpuInterpreter...
Chris.
I upgrated to latest sugar-jbuild and i greek layout works in activities like abiword of konsole, but under etoys i only get ????? when i try to insert greek uft8 chars. So i guess the utf8 support of squeak does not work "out of the box" :(
As mentioned several times before, no, Etoys does not have greek glyphs in its fonts. This is a font problem, not an encoding problem.
- Bert -
On 29/11/2007, Bert Freudenberg bert@freudenbergs.de wrote:
UTF-8 is supported. The "etoys" script now runs the VM using the "- encoding UTF-8" option.
Can you sketch how to import unicode text into Squeak? Should it be OK to copy&paste from e.g. Firefox on OSX or Windows?
I've started Squeak by double-clicking etoys.image (with Squeakland VM on OSX), installed a devanagari font, and copy&pasted text -- but I just get e.g. spaces and not real text. Help would be appreciated -- people are laughing at me for using bitmaps :-)
I've only tested with image/VM from a couple of months ago.
On Nov 29, 2007, at 12:19 , Luke Gorrie wrote:
On 29/11/2007, Bert Freudenberg bert@freudenbergs.de wrote:
UTF-8 is supported. The "etoys" script now runs the VM using the "- encoding UTF-8" option.
Can you sketch how to import unicode text into Squeak? Should it be OK to copy&paste from e.g. Firefox on OSX or Windows?
It works fine under Linux, and I cannot comment on Windows.
On the Mac, you need the ClipboardExtendedPlugin.bundle and a small fix to ExtendedClipboardMacInterface>>readTextClipboardData like this:
readTextClipboardData ^self readUTF8StringClipboardData
I'll push that to the 2.3 stream.
- Bert -
Luke,
Can you sketch how to import unicode text into Squeak? Should it be OK to copy&paste from e.g. Firefox on OSX or Windows?
With little support, you can definitely "import" text into Squeak via clipboard, file IO, or keyboard input.
However, displaying the text is another story. I did an experiment with Pango to render text from Squeak and it works somewhat... But it is yet to be tested more (and I always missed the chance to push it because we are always in the middle of preparing stuff for the next deadline and making it unstable feels so evil).
The text renderer currently we are using is written in Squeak. The theory is that everybody can modify it, but so far nobody tried to add complex script shaping handling. Relying on an external library like Pango is the second best and realistic solution.
-- Yoshiki
Hi Yoshiki!
The text renderer currently we are using is written in Squeak. The theory is that everybody can modify it, but so far nobody tried to add complex script shaping handling.
Can you give some pointers so we can get an idea of what it would take to add Devanagari in this way?
Relying on an external library like Pango is the second best and realistic solution.
How portable would the Pango option be? Would it be included with the updated Squeakland browser plugin for example?
Thanks for all the help! -Luke
The text renderer currently we are using is written in Squeak. The theory is that everybody can modify it, but so far nobody tried to add complex script shaping handling.
Can you give some pointers so we can get an idea of what it would take to add Devanagari in this way?
I need to clean up some stuff. But see that attached picture. I saved an HTML I found on the net, read it and make up a WideString consists of these characters, and create a TextMorph.
Relying on an external library like Pango is the second best and realistic solution.
How portable would the Pango option be? Would it be included with the updated Squeakland browser plugin for example?
On Windows, Mac, and Linux, ot works. For the next version of Squeakland, it won't be there, unfortunately.
-- Yoshiki
On 02/12/2007, Yoshiki Ohshima yoshiki@vpri.org wrote:
The text renderer currently we are using is written in Squeak. The theory is that everybody can modify it, but so far nobody tried to add complex script shaping handling.
Can you give some pointers so we can get an idea of what it would take to add Devanagari in this way?
I need to clean up some stuff. But see that attached picture. I saved an HTML I found on the net, read it and make up a WideString consists of these characters, and create a TextMorph.
How do you read it up and create the WideString?
The font we really want to use is this: http://nepalinux.org/fonts/samanata.ttf -- can you tell if that's supported somehow? e.g. import the font page of Nepali wikipedia into Squeak and take a screenshot?
We'll look more at the details you and Bert have sent tomorrow and then we're also meeting the experts who translate Linux/Gnome into Nepali. Maybe we already have all the details we need but anything extra might come in handy :-)
On Windows, Mac, and Linux, ot works. For the next version of Squeakland, it won't be there, unfortunately.
Out of curiosity -- how will the next Squeakland differ from the XO? We'd like very much to be able to "webify" the Squeak projects that we develop for the XO.
Thanks again ! -Luke
Luke,
I need to clean up some stuff. But see that attached picture. I saved an HTML I found on the net, read it and make up a WideString consists of these characters, and create a TextMorph.
How do you read it up and create the WideString?
Reading part is just like in a Workspace:
f := FileStream 'devanagari.txt'. f converter: UTF8TextConverter new. "this is set by default and not necessary, but to show the idea." str := f contentsOfEntireFile. str inspect.
The font we really want to use is this: http://nepalinux.org/fonts/samanata.ttf -- can you tell if that's supported somehow? e.g. import the font page of Nepali wikipedia into Squeak and take a screenshot?
If Pango supports, it should work.
We'll look more at the details you and Bert have sent tomorrow and then we're also meeting the experts who translate Linux/Gnome into Nepali. Maybe we already have all the details we need but anything extra might come in handy :-)
Great!
On Windows, Mac, and Linux, ot works. For the next version of Squeakland, it won't be there, unfortunately.
Out of curiosity -- how will the next Squeakland differ from the XO? We'd like very much to be able to "webify" the Squeak projects that we develop for the XO.
They are going to be almost the same. The features provided by Sugar won't be there but like running as a browser plugin should be possible, even the browser's world is somewhat fragmented in these days.
-- Yoshiki
Reading part is just like in a Workspace:
f := FileStream 'devanagari.txt'. f converter: UTF8TextConverter new. "this is set by default and not necessary, but to show the idea." str := f contentsOfEntireFile. str inspect.
The first line should read:
f := FileStream readOnlyFileNamed: 'devanagari.txt'.
sorry...
-- Yoshiki
Hi Yoshiki!
On 04/12/2007, Yoshiki Ohshima yoshiki@vpri.org wrote:
Reading part is just like in a Workspace:
I tried this with the Squeak that I have (Squeakland VM + Etoys 2.3 image) with the Nepali font installed (http://nepalinux.org/fonts/samanata.ttf) and when I loaded the front page of Nepali wikipedia into a TextMorph I see only question-marks.
Is that expected -- are you using an experimental Pango'ized version? If so is there some way I could use it too, preferably on all of Linux/Windows/Mac? :-)
I'd really like a way to import Nepali text into Squeak today or tomorrow -- we have two demos to do this week (one to government, one to a school) and we'll have to import the text as bitmaps again if we don't grok Squeak/unicode/fonts really soon.
I would also really appreciate a workaround to bug #4604 -- that TextMorphs lose their font selection (of a non-unicode Devanagari font) during project loading. I'm contemplating a cheezy hack with a TextMorph subclass that hardcodes its font to Devanagari in comeFullyUpOnReload:
Cheers! -Luke
On 04/12/2007, Luke Gorrie luke@member.fsf.org wrote:
I would also really appreciate a workaround to bug #4604
I managed to do this one -- actually it was quite fun finding the problem by chasing references around in the Explorer and searching for the one that doesn't serialize/deserialize the same :-) details on the trac ticket.
I'm making an effort today to understand squeak+unicode+fonts. I want to start really simple: to display a Devanagari unicode character in Squeak. I'd like to do this programatically to avoid potential problems with encoding, clipboards, etc.
Here's what I tried: 1. Drag and drop a unicode Devanagari font into Squeak from http://nepalinux.org/fonts/samanata.ttf) 2. Print a unicode character in a workspace by evaluating: Unicode value: 16r0913
I'd hoped to see a Devanagari character appear in the workspace but I only see '$?'.
I also tried this: TextMorph new contents: ((Unicode value: 16r0913) asString); openInHand which also showed as a ? even if I explicitly used the halo option to select the unicode font.
So I'd really like help with two questions: 1. How can I make it display the Devanagari character in my chosen font? 2. In general should the font selection be automatic -- if I print a unicode character should Squeak find a font that has the glyph? What's the algorithm?
More generally I'm wondering whether I need to be worried about ligature and suchlike. Is this something that Squeak needs to understand (from hints in the font?) for straight import of text?
Any help welcome :-) -Luke
On Dec 4, 2007, at 13:43 , Luke Gorrie wrote:
I'm making an effort today to understand squeak+unicode+fonts. I want to start really simple: to display a Devanagari unicode character in Squeak. I'd like to do this programatically to avoid potential problems with encoding, clipboards, etc.
Here's what I tried:
- Drag and drop a unicode Devanagari font into Squeak from
This font does not have a Unicode character mapping table, only a Windows and Macintosh one. I do not know how to map the 793 glyphs in the font to unicode code points without a proper table.
- Print a unicode character in a workspace by evaluating: Unicode
value: 16r0913
I'd hoped to see a Devanagari character appear in the workspace but I only see '$?'.
You would have to set your workspace to the Samanata font first.
I also tried this: TextMorph new contents: ((Unicode value: 16r0913) asString); openInHand which also showed as a ? even if I explicitly used the halo option to select the unicode font.
If you used a unicode font, that should have worked. This font does have Devanagari glyphs, and a unicode mapping:
http://www.nongnu.org/freefont/
If you file in the attached ttf reader hack (which I pointed to earlier) and then import FreeSans.ttf, you can get this:
I wonder if we should just switch to that font for now ...
So I'd really like help with two questions:
- How can I make it display the Devanagari character in my chosen
font?
Fix the font - or tell us how to fix the font reader without a correct character mapping table.
- In general should the font selection be automatic -- if I print a
unicode character should Squeak find a font that has the glyph? What's the algorithm?
There is no automatic font substitution - if a glyph is missing in the selected font, it is displayed as "?" or a hollow block.
More generally I'm wondering whether I need to be worried about ligature and suchlike. Is this something that Squeak needs to understand (from hints in the font?) for straight import of text?
The current Squeak text renderer does not support ligatures, composing characters etc. The Pango-based one should take care of that.
- Bert -
Thanks for the extra help!!
Now I've imported a big chunk of Nepali text from wikipedia and in the morning we'll see if it appears as proper Nepali or if it's mangled up somehow.
The current Squeak text renderer does not support ligatures, composing characters etc. The Pango-based one should take care of that.
I'd like to understand the options and issues a little better -- How soon is Pango support likely to be easily available for all platforms - days, weeks, or months?
If it's not immediate then it would be interesting to hear a sketch of how to add ligature, composing characters etc support directly into Squeak for devanagari.
Thanks again! -Luke
Bert Freudenberg wrote:
Classes and methods except for Player subclasses are not included in the project image segment currently.
- Bert -
I'm hacking on the source less project saving and have a few questions. If I add class descriptions to a change set I get outBound references to a class and I see the method names in the change set but the method bodies are not there. Wouldn't the methods show up as decompiled bodies if the source was not around ? It seems the class reference to the compiled methods is not included. How do a class reference a compiled method ?
Karl
On Nov 21, 2007, at 12:39 , karl wrote:
Bert Freudenberg wrote:
Classes and methods except for Player subclasses are not included in the project image segment currently.
- Bert -
I'm hacking on the source less project saving and have a few questions. If I add class descriptions to a change set I get outBound references to a class and I see the method names in the change set but the method bodies are not there. Wouldn't the methods show up as decompiled bodies if the source was not around ?
If the compiled methods are there, yes.
It seems the class reference to the compiled methods is not included. How do a class reference a compiled method ?
In its method dictionary.
- Bert -
Hello people, i would like to participate to the translation efferd currently underway for the eToys environment for the olpc. Can someone give me some guidelines so that i can start the greek translation? What changes should i do to the source code so that greek is included in the available languages under the etoys environment?
Thanks.
On Nov 21, 2007, at 14:51 , birbilis wrote:
Hello people, i would like to participate to the translation efferd currently underway for the eToys environment for the olpc.
Great!
Can someone give me some guidelines so that i can start the greek translation?
You can take the .pot file and start translating.
What changes should i do to the source code so that greek is included in the available languages under the etoys environment?
It should appear automatically as soon as there is a greek .mo file.
However, we do not have greek glyphs in our fonts, yet, so your translation would not be shown correctly. There is a ticket open, and it should be a rather simple fix:
https://dev.laptop.org/ticket/4894
- Bert -
Στις Τετ 21 Νοε 2007, ο/η Bert Freudenberg έγραψε:
On Nov 21, 2007, at 14:51 , birbilis wrote:
Hello people, i would like to participate to the translation efferd currently underway for the eToys environment for the olpc.
Great!
Can someone give me some guidelines so that i can start the greek translation?
You can take the .pot file and start translating.
That should be done for sure! The fact is that i wish to see how the translation is incorporated into eToys that i have currently installed in my system. So where should i place the .mo files so that the greek language support is available? And another thing, where can i download the etoys source code so i can take a look? The version i got now has a (rather big) etoys-dev.image file -precompiled i suppose..
What changes should i do to the source code so that greek is included in the available languages under the etoys environment?
It should appear automatically as soon as there is a greek .mo file.
However, we do not have greek glyphs in our fonts, yet, so your translation would not be shown correctly. There is a ticket open, and it should be a rather simple fix:
https://dev.laptop.org/ticket/4894
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On Nov 21, 2007, at 15:44 , birbilis wrote:
Στις Τετ 21 Νοε 2007, ο/η Bert Freudenberg έγραψε:
On Nov 21, 2007, at 14:51 , birbilis wrote:
Hello people, i would like to participate to the translation efferd currently underway for the eToys environment for the olpc.
Great!
Can someone give me some guidelines so that i can start the greek translation?
You can take the .pot file and start translating.
That should be done for sure! The fact is that i wish to see how the translation is incorporated into eToys that i have currently installed in my system. So where should i place the .mo files so that the greek language support is available?
Next to the other .mo files - lang/gr/LC_MESSAGES/etoys.mo
And another thing, where can i download the etoys source code so i can take a look? The version i got now has a (rather big) etoys-dev.image file -precompiled i suppose..
Not quite. You need to run that dev image using the Squeak VM, and use the browser tools in there. It is not "pre-compiled" but an ever evolving snapshot of live objects, including classes and methods, which of course are objects, too. Squeak was derived from the original Smalltalk, which abandoned the idea of starting from source code more than 30 years ago. Indeed, some objects in that image are more than 30 years old.
Welcome to *real* OO ;)
- Bert -
What changes should i do to the source code so that greek is included in the available languages under the etoys environment?
It should appear automatically as soon as there is a greek .mo file.
However, we do not have greek glyphs in our fonts, yet, so your translation would not be shown correctly. There is a ticket open, and it should be a rather simple fix:
https://dev.laptop.org/ticket/4894
- Bert -
Hello,
While back in May and June, Christos (who wrote an email below on different topic) and friends are working on Greek support.
http://lists.laptop.org/pipermail/etoys/2007-June/000620.html
The VM wasn't quite ready and he was working on it, but we got around to try a version that might (or might not) work for a saner way to input Greek. The external translation mechanism wasn't there back then but now we basically have it.
The image has support for Greek and we have a separated "font file" for Greek but it is in pixel fonts and doesn't look remotely nice on XO. Chris tried to import some fonts but reported the image became too big. I didn't look at it closely around that time. I think he used Bert's fix to load these fonts.
Yes, the situation is better now than back then and it would be nice to give it a shot one more time. You might want to contact Chris to coordinate translation effort.
-- Yoshiki
At Wed, 21 Nov 2007 16:44:18 +0200, birbilis wrote:
[1 <multipart/signed (7bit)>] [1.1 <text/plain; iso-8859-7 (quoted-printable)>] Στις Τετ 21 Νοε 2007, ο/η Bert Freudenberg έγραψε:
On Nov 21, 2007, at 14:51 , birbilis wrote:
Hello people, i would like to participate to the translation efferd currently underway for the eToys environment for the olpc.
Great!
Can someone give me some guidelines so that i can start the greek translation?
You can take the .pot file and start translating.
That should be done for sure! The fact is that i wish to see how the translation is incorporated into eToys that i have currently installed in my system. So where should i place the .mo files so that the greek language support is available? And another thing, where can i download the etoys source code so i can take a look? The version i got now has a (rather big) etoys-dev.image file -precompiled i suppose..
What changes should i do to the source code so that greek is included in the available languages under the etoys environment?
It should appear automatically as soon as there is a greek .mo file.
However, we do not have greek glyphs in our fonts, yet, so your translation would not be shown correctly. There is a ticket open, and it should be a rather simple fix:
https://dev.laptop.org/ticket/4894
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
[1.2 This is a digitally signed message part. <application/pgp-signature (7bit)>]
[2 <text/plain; us-ascii (7bit)>] _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
birbilis -
Chris Petsos -
Hilaire Fernandes -
karl -
Karl
-
korakurider -
korakurider＠yahoo.co.jp
-
Luke Gorrie -
stephane ducasse -
Ted Kaehler -
Yoshiki Ohshima