September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Off Topic: Children 3-13yr english program -- 4 weeks free access

by Ben Coman

On Tue, Feb 2, 2016 at 9:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Jul 20, 2015 at 11:17 PM, Ben Coman <btc(a)openinworld.com> wrote: >> greetings all, >> >> This is a long way off topic, but a random chance someone in the community >> with kids learning english may find it useful. The past year I've had my 4yr >> & 6yr old girls doing Reading Eggs. Its aimed at native-english children >> ages 3-13 (starting with a test to place kids at a stimulating level). >> >> Its been beneficial for my kids, so I'm forwarding this offer to the >> community. > > There was some appreciation for this six months ago. Another just > arrived, so I thought I'd share it again. In another half year I > guess I'll get another, so if anyone doesn't want me to post again > then, let me know. > > More background info... ABC is Australia's government sponsored > national TV broadcaster (yay, no commercials!). They produced a web > site to help kids literacy. It was fantastic for my kids, although my > 8 year old got bored with it later on, so it seems more suited for > younger ages. I've had no complaints (yet), and six months later another 5 week free pass arrived. I am a bit hesitant to continue forwarding them since its so far off topic, but I think there is real value for my online friends. http://readingeggs.com.au/pas2/?M=A2CC1945-52FE-4E22-8C1A-1614649ECE83 My youngest (now 6) is starting to get a bit bored with the final 20 levels (of 120) so again it seems to work better for the younger kids. Non-native-english kids may differ. btw, you don't need the book packs. They are all included in the online app. cheers -ben

Sept. 27, 2016

Re: [Pharo-dev] [REMEMBER] Tech meeting rue 27/09 16UTC - We'll talk about current PharoVM ongoing development

by stepharo

> I noticed only in a side conversation recently (rather than an > announcement, did I miss something?) that the change of development > process to now just submit slices to inbox and configurations get > sorted later (which makes things simpler - but I wonder how > configurations are then maintained. Manually would seem susceible to > error is fixes being dropped - so could we get an update of > development process end to end comparing bug-fixing versus feature > development. If too late notice, then could it be lined up for > subsequent meeting? Hi ben People must maintain their configuration. Now for external projects we do not want deadlock to move so we decided that we publish changes and that the maintainers of external projects can just merge back and continue to propose their change using configurations. Is it clearer? Stef

Sept. 27, 2016

Re: [Pharo-dev] [REMEMBER] Tech meeting rue 27/09 16UTC - We'll talk about current PharoVM ongoing development

by Ben Coman

I noticed only in a side conversation recently (rather than an announcement, did I miss something?) that the change of development process to now just submit slices to inbox and configurations get sorted later (which makes things simpler - but I wonder how configurations are then maintained. Manually would seem susceible to error is fixes being dropped - so could we get an update of development process end to end comparing bug-fixing versus feature development. If too late notice, then could it be lined up for subsequent meeting? cheers -ben On Mon, Sep 26, 2016 at 10:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Ah yes, I forget the âsmall detailâ of linking my channel :) > > https://www.livecoding.tv/estebanlm/ > > (I never tried, so this can fail ;) > > cheers, > Esteban > > On 26 Sep 2016, at 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hello, > > I will handle the first tech meeting tomorrow, as preview. > After several considerations, I will be trying âlivecoding.tvâ (no idea if > this is worst or better than twitchâ¦ and Iâm not very happy with the fact > that this is a âtv formatâ and not a âconversation formatâ, but well, weâll > see how it goes, maybe weâll need to review this later). > > Subject of meeting tomorrow is a general overview about current work on > PharoVM, so prepare your questions, and see you there! > > cheers, > Esteban > >

Sept. 26, 2016

Re: [Pharo-dev] FFI callout arguments - references to internal objects

by Ben Coman

Hi Esteban, Your advice lead me to make some progress. Could you have a review? http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-5-client-data-a… Its perhaps a little low level and I'd like to make CXClientData a wrapper for some of the complexity. But time to snooze now. cheers -ben On Sun, Sep 25, 2016 at 4:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Ben, > > I will take a better look tomorrow morning, but as first sight, seems to be that you want to declare SomeObject and receive it as argument to the callback, while you are receiving just an ExternalAddress. > If is that the problem what happens is that callbacks do not handle *any type* as the rest of UFFIâ¦ they just handle standard C types, so you will receive an ExternalAddress isnât? > You need to obtain the actual object as you need it. I see two strategies: > > 1) just create the object using SomeObject>>#fromHandle: This work fine if object is stateless and just want to access itâs defined vocabulary. > 2) orâ¦ you can just cachÃ© the data someplace and then find it using the ExternalAddress as index. > > (I hope I interpreted the problem correctlyâ¦ Iâm a bit sleep here :P) > > cheers, > Esteban > > >> On 24 Sep 2016, at 19:40, Ben Coman <btc(a)openInWorld.com> wrote: >> >> I'm seeking some support for Part 5 of my FFI tutorial >> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-5-client-data-a… >> >> where I'm trying to replicate some C code where: >> * client_data is a void pointer, and an argument to a callout function >> * a reference to some data (an int, or a struct) is passed to the >> callout function as the client_data >> * the callout function passes that same client_data to a callback >> function which casts the client-data to the required type >> >> How can I replicate that with UFFI? The key thing is that *any* type >> can be passed via client_data. So for a normal Pharo object defined >> like... >> >> Object subclass: MyObject >> instanceVariables: 'x y' >> >> myobject := MyObject new x:3 y:4. >> >> I want to pass a reference to myobject to the callout, and in the >> callback dereference client_data to get myobject that I can operate on >> normally. >> >> Is this possible with current infrastructure, or would it need >> something new like FFIInternalPinnedReference to wrap myobject for the >> callout and unwrap it in the callback? >> >> cheers -ben >> > >

Sept. 26, 2016

Re: [Pharo-dev] Traits explicitRequirement -- and TClassDescription

by stepharo

I would like to remove traits users from metaclass class description. I do not think that they are worht hteh complexity they bring. Stef Le 26/9/16 Ã 16:16, Ben Coman a Ã©crit : > I'm not familiar with the #explicitRequirement I see sent in Slice 17798. > Could someone explain why that is better than calling... > self setName: aSymbol. > > > Also, another thing I've been curious about for a while, what is the > advantage of having TClassDescription when it only has one user > ClassDescription? > > > cheers -ben > >

Sept. 26, 2016

Re: [Pharo-dev] [REMEMBER] Tech meeting rue 27/09 16UTC - We'll talk about current PharoVM ongoing development

by Esteban Lorenzano

Ah yes, I forget the âsmall detailâ of linking my channel :) https://www.livecoding.tv/estebanlm/ <https://www.livecoding.tv/estebanlm/> (I never tried, so this can fail ;) cheers, Esteban > On 26 Sep 2016, at 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hello, > > I will handle the first tech meeting tomorrow, as preview. > After several considerations, I will be trying âlivecoding.tvâ (no idea if this is worst or better than twitchâ¦ and Iâm not very happy with the fact that this is a âtv formatâ and not a âconversation formatâ, but well, weâll see how it goes, maybe weâll need to review this later). > > Subject of meeting tomorrow is a general overview about current work on PharoVM, so prepare your questions, and see you there! > > cheers, > Esteban

Sept. 26, 2016

[REMEMBER] Tech meeting rue 27/09 16UTC - We'll talk about current PharoVM ongoing development

by Esteban Lorenzano

Hello, I will handle the first tech meeting tomorrow, as preview. After several considerations, I will be trying âlivecoding.tvâ (no idea if this is worst or better than twitchâ¦ and Iâm not very happy with the fact that this is a âtv formatâ and not a âconversation formatâ, but well, weâll see how it goes, maybe weâll need to review this later). Subject of meeting tomorrow is a general overview about current work on PharoVM, so prepare your questions, and see you there! cheers, Esteban

Sept. 26, 2016

Re: [Pharo-dev] Traits explicitRequirement -- and TClassDescription

by Max Leske

> On 26 Sep 2016, at 15:16, Ben Coman <btc(a)openinworld.com> wrote: > > I'm not familiar with the #explicitRequirement I see sent in Slice 17798. > Could someone explain why that is better than calling... > self setName: aSymbol. > Traits donât have instance variables, so you somehow need to tell users to implement the methods that are supposed to write / read instance variables. Also, as traits are not classes, #subclassResponsibility isnât entirely correct semantically. > > Also, another thing I've been curious about for a while, what is the > advantage of having TClassDescription when it only has one user > ClassDescription? > > > cheers -ben >

Sept. 26, 2016

Traits explicitRequirement -- and TClassDescription

by Ben Coman

I'm not familiar with the #explicitRequirement I see sent in Slice 17798. Could someone explain why that is better than calling... self setName: aSymbol. Also, another thing I've been curious about for a while, what is the advantage of having TClassDescription when it only has one user ClassDescription? cheers -ben

Sept. 26, 2016

Full-Time Academic Position, University of Chile

by Alexandre Bergel

Dear All, We have an open academic position. Full-Time Academic Position Computer Science Department, University of Chile http://www.dcc.uchile.cl The Computer Science Department of the University of Chile (DCC) is offering a full-time permanent position to carry out research and teaching, at the undergraduate and graduate levels. The DCC is the leading Computer Science Department in Chile, and one of the most active in Latin America. It pioneered the use of Unix and the adoption of the Internet in Chile. Today, it has 22 full-time professors, 10 of which come from Argentina, Uruguay, Belgium, France, and Ireland. We carry out high-quality research, publishing frequently in the most prestigious international conferences and journals. The DCC is in charge of the undergraduate Computer Science program within the Engineering Faculty of the University of Chile, reaching a thousand students in the first year of Engineering, and taking care of the CS specialization from the third year onward for over two hundreds students. Our MSc and PhD programs attract the best students from Latin America, with currently around fifty students in each program. The DCC offers newcomers an individual office and necessary equipment, as well as a starting grant for initiating their research activities; further funding is then obtained permanently upon publications. This is usually complemented with funds from a personal research project obtained from Conicyt, the national research agency, and/or with funds from larger collaborative projects. An assistant professor can supervise students of any level and have a light administrative load. Professors in our department are expected to teach three courses per year; typically one of these courses is an elective that the professor can define according to his/her interests. The salary provided by the University is very competitive, and depends on the ranking (assistant, associate, full); it is complemented with research projects. The successful candidate should be an active researcher with a PhD in Computer Science (or about to obtain it before starting the position). We are interested in any area of Computer Science, and both junior and senior researchers are welcome to apply. The candidate will be evaluated on the basis of both research and teaching activities, impact, as well as vision for the future. Important Dates We accept applications until November 30, 2016. The expected starting date is March 1, 2017 (August 2017 at the latest). Location The DCC is located in Santiago de Chile. Santiago is the capital and largest city in Chile, with a lively cultural scene and delectable cuisine. It is located at the foothills of the Andes, with over 300 days of sun per year, and both ski slopes and the Pacific coast at a 1-hour drive. Santiago is well-connected through direct flights to major hubs in both Europe and the USA. Chile is a country with a lot to offer especially to nature lovers, with over 4,300 km of seashore and mountains, filled with stunning landscapes and national parks stretching from Patagonia to the Atacama desert. For enquiries, please contact Prof. Gonzalo Navarro at gnavarro(a)dcc.uchile.cl -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 26, 2016