- Pharo-users - lists.pharo.org

Re: [Pharo-users] #select was sent to nil

by Tudor Girba

Thanks for looking into this problem! Doru > On Jan 16, 2019, at 10:57 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > The bug seems to have been introduce in Pharo7.0-SNAPSHOT.build.102.sha.3f660fc.arch.64bit by merging the pull request https://github.com/pharo-project/pharo/pull/1847 > > On Wed, Jan 16, 2019 at 1:32 AM Hilaire via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Indeed, seems to only happen in a subclass of BlEement. > > Hilaire > > Le 15/01/2019 Ã 21:33, Andrei Chis a Ã©crit : > > It happens if you create methods in a class having a superclass with > > traits. For example if you create a subclass of BlElement you will get > > this error. > > > > What class are you editing when you get this errror? > > > -- > Dr. Geo > http://drgeo.eu > > > -- www.feenk.com "Some battles are better lost than fought."

Jan. 16, 2019

Re: [Pharo-users] #select was sent to nil

by Andrei Chis

The bug seems to have been introduce in Pharo7.0-SNAPSHOT.build.102.sha.3f660fc.arch.64bit by merging the pull request https://github.com/pharo-project/pharo/pull/1847 On Wed, Jan 16, 2019 at 1:32 AM Hilaire via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Indeed, seems to only happen in a subclass of BlEement. > > Hilaire > > Le 15/01/2019 Ã 21:33, Andrei Chis a Ã©crit : > > It happens if you create methods in a class having a superclass with > > traits. For example if you create a subclass of BlElement you will get > > this error. > > > > What class are you editing when you get this errror? > > > -- > Dr. Geo > http://drgeo.eu > > > >

Jan. 16, 2019

Re: [Pharo-users] Transforming objects

by jtuchel＠objektfabrik.de

LoÃ¯c, Am I correct in assuming you are thinking about a model in which a plant can have a growing and shrinking list of organs over time and some of them even have (a growing list of) stages? I am not an expert on the matter, but to me the stages idea sounds good. It even allows for historic information (it was a bud from Date1 to Date2 and since then it is a flower). So transformation would be adding a new Stage and "terminate" the previous one. With this you can ask a plant about its current stage on the reproductive front and maybe other organs as well at any point time. This may be helpful if you want to build an animation of the plant's development over time. You can have separate life cycles for each organ. Does the plant transform in the real world? I mean, is a cherry tree still a cherry tree, even if it's not blooming any more and carries fruit instead? So why transform the object in its abstract model? Just a thought, maybe better ideas show up. Joachim Am 16.01.19 um 10:15 schrieb LoÃ¯c PagÃ¨s: > Dear Pharo users, > > I develop software dedicated to the simulation of plant development > and 3D architecture. > > In the past, I used Java, but I am very interested in translating code > in Pharo. I appreciated very much the language and the course. > > I have a question for you all : > > During plant development (ontogeny), new organs appear, that are > gradually tranformed. For example, a bud can make a flower, and then a > fruit. > > Organs are conveniently modelled as classes. During the course, I > learned that it was better to make several classes (bud, flower, > fruit) instead of a "fat class" such as "reproductive organ" with many > attributes and stages (bud stage, flower stage, fruit stage). I wonder > how to transform an object into another one, to represent for example > the fact that the flower may become a fruit. > > Maybe a naive question ? > > Thanks for your lights ! > > LoÃ¯c > > > >

Jan. 16, 2019

Transforming objects

by LoÃ¯c PagÃ¨s

Dear Pharo users, I develop software dedicated to the simulation of plant development and 3D architecture. In the past, I used Java, but I am very interested in translating code in Pharo. I appreciated very much the language and the course. I have a question for you all : During plant development (ontogeny), new organs appear, that are gradually tranformed. For example, a bud can make a flower, and then a fruit. Organs are conveniently modelled as classes. During the course, I learned that it was better to make several classes (bud, flower, fruit) instead of a "fat class" such as "reproductive organ" with many attributes and stages (bud stage, flower stage, fruit stage). I wonder how to transform an object into another one, to represent for example the fact that the flower may become a fruit. Maybe a naive question ? Thanks for your lights ! LoÃ¯c

Jan. 16, 2019

Re: [Pharo-users] A volunteer is desperately needed

by horrido

Fantastic! I have your email, so we can begin collaboration. David Buck has offered to give continuing advice and guidance, should you need it. I may start looking into Bloc and Woden, as well. I don't know how helpful I'll be, since I haven't done much programming in the past decade. Much thanks. Ben Coman wrote > Hi Richard, > > I like the way you've persevered to get it to this stage, so I'll be glad > to pitch in > now that its got some physicality to the project. > > I'm not currently familiar with Bloc and Woden. They are systems I've > been wanting to learn more about but I've not had a "need" to drive me to > it. > So I'd value some goal directed learning to help me focus on it. > > @all, what recipies are you using to kickoff your Visualworks to Pharo > ports? > I know I've seen several options mentioned before, but I can't pin them > down in the archives. > Also I imagine this area is improving over time, so looking for updated > info. > > cheers -ben > > > On Wed, 16 Jan 2019 at 05:44, Richard Kenneth Eng < > horrido.hobbies@ > > > wrote: > >> I guess I should provide some more information about the competition. If >> you visit jrmpc.ca, you will see what it is that David was coding under >> the section, "Competition Rules." >> >> Here are some screen shots: >> >> A 2D view: >> [image: 2d-view.png] >> >> An OpenGL view: >> [image: opengl-view.png] >> >> The OpenGL view is *only* for making videos of the Competition to show to >> the public. The teams will be working with the 2D view. >> >> Attached is the VisualWorks source that needs to be converted to Pharo. I >> imagine the real work is re-implementing the graphics using Bloc and >> Woden. >> The competition engine should be fairly portable (Famous Last Words). >> >> It's not *that* big of an application. After all, David did it in only >> six weeks, even with his really busy schedule. >> >> I suppose I could try to do it myself, but since I'm hardly a Pharo >> expert, it would take me much, much longer. Could I do it by September? >> Maybe. I don't know that I'd put money on me, though. >> >> R >> >> On Tue, 15 Jan 2019 at 11:21, Richard Kenneth Eng < >> > horrido.hobbies@ >> wrote: >> >>> As you know, the James Robertson Memorial Programming Competition (or >>> JRMPC) is proceeding. You may recall that the decision was made to use >>> VisualWorks for the competition. >>> >>> However, I now realize that it was the wrong decision. VisualWorks >>> presents a number of issues, such as: >>> >>> 1. licensing, esp. to minors (all high school students are minors) >>> 2. awkward installation >>> 3. poor community support â their forum is dead and their mailing >>> list is a PITA to use >>> 4. lack of GitHub support â GitHub rules the programming world now >>> 5. aging IDE and lack of innovation >>> >>> All of this makes for a bad image, which is disastrous from the >>> marketing >>> perspective. >>> >>> David Buck coded the competition in VisualWorks because he wasn't >>> familiar with Pharo. His code is quite functional and he says it's about >>> 80% complete. He started coding just six weeks ago! So the remaining 20% >>> shouldn't be arduous. >>> >>> Here are the things left to do: >>> >>> - complete the OpenGL rendering of the competition and video >>> recording >>> - add code to scan source code submitted by students to prevent >>> malware and cheating >>> - add code to allow full automation of the competition >>> >>> The OpenGL rendering and video recordings will make the competition look >>> much more attractive to the public. This is vital because the >>> competition >>> is a promotional and marketing event, and it has to look really good. >>> >>> I need a Pharo expert to take over from David and convert the code base >>> to Pharo, then finish the remaining 20%. This needs to be done by >>> September. >>> >>> I'd really hate to scrap the project when we've made so much progress >>> already. I just need one Pharoer who truly believes that this marketing >>> event is worthwhile. Please give it serious consideration. >>> >>> Thanks. >>> >> > > > 2d-view.png (21K) > <http://forum.world.st/attachment/5093576/0/2d-view.png> > opengl-view.png (102K) > <http://forum.world.st/attachment/5093576/1/opengl-view.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 16, 2019

Re: [Pharo-users] A volunteer is desperately needed

by tomo

Hi, For OpenGL stuff, I partially ported an OpenGL library for VisualWorks called "Jun" to Pharo. The Pharo version is available at https://github.com/tomooda/Jun . The 3D pic that Richard posted looks like a simple polygon with a 3D image as a texture. The following code does something like that. | square form rc projection morph | square := Jun3dDisplayPolygon points: (Array with: -1 ,, 0 ,, -1 with: 1 ,, 0 ,, -1 with: 1 ,, 0 ,, 1 with: -1 ,, 0 ,, 1). square setTexture: (JunTexture on: JunSystem logo) points: (Array with: 0 ,, 1 with: 1 ,, 1 with: 1 ,, 0 with: 0 ,, 0). projection := JunPerspectiveProjection eyePoint: 2,, -2 ,, 2 sightPoint: 0 ,, 0 ,, 0 upVector: 0 ,, 0 ,, 1 fovy: 60 asDegrees near: 0.1 far: 100.0. form := Form extent: 500 @ 500 depth: 32. rc := form renderingContext. rc backgroundColor: (Color white alpha: 0.0). rc projection: projection. rc clear. rc ambientLight: Color gray. rc lightIndex: 0 parallel: projection eyePoint negated color: Color gray. square renderOn: rc. rc flush. form asMorph openInWindow Best Regards, --- tomo -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 16, 2019

Re: [Pharo-users] A volunteer is desperately needed

by Ben Coman

Hi Richard, I like the way you've persevered to get it to this stage, so I'll be glad to pitch in now that its got some physicality to the project. I'm not currently familiar with Bloc and Woden. They are systems I've been wanting to learn more about but I've not had a "need" to drive me to it. So I'd value some goal directed learning to help me focus on it. @all, what recipies are you using to kickoff your Visualworks to Pharo ports? I know I've seen several options mentioned before, but I can't pin them down in the archives. Also I imagine this area is improving over time, so looking for updated info. cheers -ben On Wed, 16 Jan 2019 at 05:44, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > I guess I should provide some more information about the competition. If > you visit jrmpc.ca, you will see what it is that David was coding under > the section, "Competition Rules." > > Here are some screen shots: > > A 2D view: > [image: 2d-view.png] > > An OpenGL view: > [image: opengl-view.png] > > The OpenGL view is *only* for making videos of the Competition to show to > the public. The teams will be working with the 2D view. > > Attached is the VisualWorks source that needs to be converted to Pharo. I > imagine the real work is re-implementing the graphics using Bloc and Woden. > The competition engine should be fairly portable (Famous Last Words). > > It's not *that* big of an application. After all, David did it in only > six weeks, even with his really busy schedule. > > I suppose I could try to do it myself, but since I'm hardly a Pharo > expert, it would take me much, much longer. Could I do it by September? > Maybe. I don't know that I'd put money on me, though. > > R > > On Tue, 15 Jan 2019 at 11:21, Richard Kenneth Eng < > horrido.hobbies(a)gmail.com> wrote: > >> As you know, the James Robertson Memorial Programming Competition (or >> JRMPC) is proceeding. You may recall that the decision was made to use >> VisualWorks for the competition. >> >> However, I now realize that it was the wrong decision. VisualWorks >> presents a number of issues, such as: >> >> 1. licensing, esp. to minors (all high school students are minors) >> 2. awkward installation >> 3. poor community support â their forum is dead and their mailing >> list is a PITA to use >> 4. lack of GitHub support â GitHub rules the programming world now >> 5. aging IDE and lack of innovation >> >> All of this makes for a bad image, which is disastrous from the marketing >> perspective. >> >> David Buck coded the competition in VisualWorks because he wasn't >> familiar with Pharo. His code is quite functional and he says it's about >> 80% complete. He started coding just six weeks ago! So the remaining 20% >> shouldn't be arduous. >> >> Here are the things left to do: >> >> - complete the OpenGL rendering of the competition and video recording >> - add code to scan source code submitted by students to prevent >> malware and cheating >> - add code to allow full automation of the competition >> >> The OpenGL rendering and video recordings will make the competition look >> much more attractive to the public. This is vital because the competition >> is a promotional and marketing event, and it has to look really good. >> >> I need a Pharo expert to take over from David and convert the code base >> to Pharo, then finish the remaining 20%. This needs to be done by September. >> >> I'd really hate to scrap the project when we've made so much progress >> already. I just need one Pharoer who truly believes that this marketing >> event is worthwhile. Please give it serious consideration. >> >> Thanks. >> >

Jan. 16, 2019

Re: [Pharo-users] A volunteer is desperately needed

by Richard Kenneth Eng

I guess I should provide some more information about the competition. If you visit jrmpc.ca, you will see what it is that David was coding under the section, "Competition Rules." Here are some screen shots: A 2D view: [image: 2d-view.png] An OpenGL view: [image: opengl-view.png] The OpenGL view is *only* for making videos of the Competition to show to the public. The teams will be working with the 2D view. Attached is the VisualWorks source that needs to be converted to Pharo. I imagine the real work is re-implementing the graphics using Bloc and Woden. The competition engine should be fairly portable (Famous Last Words). It's not *that* big of an application. After all, David did it in only six weeks, even with his really busy schedule. I suppose I could try to do it myself, but since I'm hardly a Pharo expert, it would take me much, much longer. Could I do it by September? Maybe. I don't know that I'd put money on me, though. R On Tue, 15 Jan 2019 at 11:21, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > As you know, the James Robertson Memorial Programming Competition (or > JRMPC) is proceeding. You may recall that the decision was made to use > VisualWorks for the competition. > > However, I now realize that it was the wrong decision. VisualWorks > presents a number of issues, such as: > > 1. licensing, esp. to minors (all high school students are minors) > 2. awkward installation > 3. poor community support â their forum is dead and their mailing list > is a PITA to use > 4. lack of GitHub support â GitHub rules the programming world now > 5. aging IDE and lack of innovation > > All of this makes for a bad image, which is disastrous from the marketing > perspective. > > David Buck coded the competition in VisualWorks because he wasn't familiar > with Pharo. His code is quite functional and he says it's about 80% > complete. He started coding just six weeks ago! So the remaining 20% > shouldn't be arduous. > > Here are the things left to do: > > - complete the OpenGL rendering of the competition and video recording > - add code to scan source code submitted by students to prevent > malware and cheating > - add code to allow full automation of the competition > > The OpenGL rendering and video recordings will make the competition look > much more attractive to the public. This is vital because the competition > is a promotional and marketing event, and it has to look really good. > > I need a Pharo expert to take over from David and convert the code base to > Pharo, then finish the remaining 20%. This needs to be done by September. > > I'd really hate to scrap the project when we've made so much progress > already. I just need one Pharoer who truly believes that this marketing > event is worthwhile. Please give it serious consideration. > > Thanks. >

Jan. 15, 2019

Re: #select was sent to nil

by Hilaire

Indeed, seems to only happen in a subclass of BlEement. Hilaire Le 15/01/2019 Ã 21:33, Andrei Chis a Ã©critÂ : > It happens if you create methods in a class having a superclass with > traits. For example if you create a subclass of BlElement you will get > this error. > > What class are you editing when you get this errror? > -- Dr. Geo http://drgeo.eu

Jan. 15, 2019

Re: [Pharo-users] #select was sent to nil

by Andrei Chis

It happens if you create methods in a class having a superclass with traits. For example if you create a subclass of BlElement you will get this error. What class are you editing when you get this errror? Cheers, Andrei On Tue, 15 Jan 2019, 21:17 Hilaire <hilaire(a)drgeo.eu wrote: > Yes, it happens on two images. One fresh P7 where I installed GToolkit > and DrGeo then use its tonel repo (save changes). And the other one from > the GToolkit image download from gtoolkit.org and installed DrGeo then > use its tonel repo (save changes) > > I don't use trait in DrGeo. > > Hilaire > > Le 15/01/2019 Ã 10:17, Denis Kudriashov a Ã©crit : > > Can you reproduce it? > > -- > Dr. Geo > http://drgeo.eu > > > >

Jan. 15, 2019