January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Do you want to discuss about papers?

by Janko MivÅ¡ek

Mariano, That's a very good idea and useful also for us practitioners to get and implement some new ideas from theoretic works out there. So I am for this new mailing list! Janko On 30. 01. 2010 14:35, Mariano Martinez Peck wrote: > Hi folks. Before sending this email to all smalltalk mailing lists, I > first wanted to ask you what do you think. > > I am new in the world of the research and about reading and discussing > about papers. If what I propose already exist, forget this mail and > please tell me where is it. > > I was thinking to have a place, an environment (mailing list), where we > can freely discuss about Smalltalk or OO in general papers. At the > beginning I though to put this inside the Pharo mailing list but then I > though it is better to do a new mailing list where all smalltalkers of > all flavors can join and discuss. > > The main purpose about that list is: > > - be able to FREELY discuss about papers about Smalltalk or OO in > general. I say freely because maybe someone gives an opinion of a paper > that the person who wrote it is also in this place. We are all > professional and I think we can discuss with respect. > - LEARN. > > Other uses: > - Don't reinvent the wheel. Maybe I wanted to do something and I read > that XXX person did YYY. So, I can look at it. > - Be aware of what other people is doing, working, writing and learning > - Have different opinions of a certain topic / paper. > - A little step to join all the Smalltalk community in one place. We can > meet people, join forces, etc. > - Help in the preparation, ANN, collaborate, etc in Workshops, > conferences, and so on > - Ask for help on review. Several times someone has several papers to > review for a certain conference. This can be a place to ask for that help. > - Publish papers that were rejected from someone. How many times some > papers where rejected but do you still read it and find it useful ? > - Ask for feedback for a paper before submitting it in a conference/workshop > - Educate people and being educated > - Share latex template, commands, or tricks related to smalltalk code > for example > - Discuss about research in general > - Ask for a certain topic. Suppose I want to start to work in XXX topic, > I can ask to see if someone knows related papers or work. > - others > > I will give you an example: this week I have been reading a paper about > LOOM - Large Object Oriented Memory. This paper is from ECOOP 1986 > (the only thing an Argentinian can think about that year is Maradona's > goals to England in Mexico ;) ). I was one year old at that time. LOOM > was based in Smalltalk 80. I had no idea about that. I had to read some > chapters of the blue book first in order to then understand LOOM. I have > ever seen LOOM code, I don't know what happened with it, etc. So, maybe > there is someone who even saw LOOM in live, he saw the code, he knows > what happened, if it worked really or not, the advantages and drawbacks, > the repercussion it had, etc. That information, those opinions, you > cannot get it from other place. > > So, what do you think? Do you like the idea or has no sense ? If you > like and has sense, I will create the mailing list and send it to all > Smalltalk mailing lists I know. > > In two words: DISCUSS AND LEARN. > > Cheers > > Mariano -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 30, 2010

Re: [Pharo-project] [squeak-dev] Monticello HTTPS

by Mariano Martinez Peck

Hi folks. I think this guy has a point here. Does someone have an answer ? > > I'm curious as to how a company would protect it's source using Smalltalk > when the developers are not all set up to dial in via e.g. VPN. Maybe > somebody could give me a hint as to how a company would realize a secure > distributed development repository? Or is Monticello not the right choice in > this case? > > Many regards, > > Ole. >

Jan. 30, 2010

[Pharo-project] Do you want to discuss about papers?

by Mariano Martinez Peck

Hi folks. Before sending this email to all smalltalk mailing lists, I first wanted to ask you what do you think. I am new in the world of the research and about reading and discussing about papers. If what I propose already exist, forget this mail and please tell me where is it. I was thinking to have a place, an environment (mailing list), where we can freely discuss about Smalltalk or OO in general papers. At the beginning I though to put this inside the Pharo mailing list but then I though it is better to do a new mailing list where all smalltalkers of all flavors can join and discuss. The main purpose about that list is: - be able to FREELY discuss about papers about Smalltalk or OO in general. I say freely because maybe someone gives an opinion of a paper that the person who wrote it is also in this place. We are all professional and I think we can discuss with respect. - LEARN. Other uses: - Don't reinvent the wheel. Maybe I wanted to do something and I read that XXX person did YYY. So, I can look at it. - Be aware of what other people is doing, working, writing and learning - Have different opinions of a certain topic / paper. - A little step to join all the Smalltalk community in one place. We can meet people, join forces, etc. - Help in the preparation, ANN, collaborate, etc in Workshops, conferences, and so on - Ask for help on review. Several times someone has several papers to review for a certain conference. This can be a place to ask for that help. - Publish papers that were rejected from someone. How many times some papers where rejected but do you still read it and find it useful ? - Ask for feedback for a paper before submitting it in a conference/workshop - Educate people and being educated - Share latex template, commands, or tricks related to smalltalk code for example - Discuss about research in general - Ask for a certain topic. Suppose I want to start to work in XXX topic, I can ask to see if someone knows related papers or work. - others I will give you an example: this week I have been reading a paper about LOOM - Large Object Oriented Memory. This paper is from ECOOP 1986 (the only thing an Argentinian can think about that year is Maradona's goals to England in Mexico ;) ). I was one year old at that time. LOOM was based in Smalltalk 80. I had no idea about that. I had to read some chapters of the blue book first in order to then understand LOOM. I have ever seen LOOM code, I don't know what happened with it, etc. So, maybe there is someone who even saw LOOM in live, he saw the code, he knows what happened, if it worked really or not, the advantages and drawbacks, the repercussion it had, etc. That information, those opinions, you cannot get it from other place. So, what do you think? Do you like the idea or has no sense ? If you like and has sense, I will create the mailing list and send it to all Smalltalk mailing lists I know. In two words: DISCUSS AND LEARN. Cheers Mariano

Jan. 30, 2010

Re: [Pharo-project] peek and friends

by StÃ©phane Ducasse

thanks! On Jan 30, 2010, at 9:23 AM, Igor Stasenko wrote: > On 29 January 2010 23:09, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> hi Igor >> >> finally should I integrate >> http://bugs.squeak.org/view.php?id=7446 ? >> I was waiting because you said you were confused >> > > Yes, integrate that, since it deals with issue that #peek should > answer the same byte as following #next. > > We turned discussion into other issues, not related to this _bug_ (but > related to #peek behavior), concerning what will happen if timeout > appear. Here the last version(s) of both peek and next which taking > care about it: > > > !SocketStream methodsFor: 'stream in' stamp: 'Igor.Stasenko 1/15/2010 02:02'! > next > "Return next byte, if inBuffer is empty > we recieve some more data and try again." > > [self isDataAvailable] whileFalse: [ > self receiveData. self atEnd ifTrue: [ ^ nil ]]. > > ^inBuffer at: (lastRead := lastRead + 1) > ! ! > > !SocketStream methodsFor: 'stream in' stamp: 'Igor.Stasenko 1/15/2010 01:33'! > peek > "Return next byte, if inBuffer is empty > we recieve some more data and try again. > Do not consume the byte." > > [self isDataAvailable] whileFalse: [ > self receiveData. self atEnd ifTrue: [ ^ nil ]]. > > ^inBuffer at: lastRead +1! ! > > > As you can see, the only difference between peek and next is that one > advancing the buffer pointer, while other not. > >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 30, 2010

Re: [Pharo-project] Fun with ProfStef

by Mariano Martinez Peck

It would be fun to put a BIG popup in the first time the user evaluates a goto: saying that goto: href, etc, are not allowed in Smalltalk :) On Sat, Jan 30, 2010 at 10:59 AM, Danny Chan <chan_dhf(a)yahoo.de> wrote: > Hi Dale > > > In putting together a couple of ProfStef tutorials last weekend, I found > > that I'd like to be able to #goto a lesson (out of sequence), > essentially > > hitting a branch point where the student can skip a set of lessons or > move > > to a different set of lessons. My thought was something like: > > > > ProfStef goto: #lesson15 "jump to lesson15" > > We have now split the GUI changes I did into a separate package > ProfStefBrowser. In this I have something like this > > ProfStefBrowser goto: SmalltalkSyntaxTutorial lessonAt: 3 > > This is used to replace the current lesson when I click in the tutorial > tree. > I just checked, and if I move three methods up the hierarchy, it works > exactly > the same in the ProfStef core. > > Laurent, if you like this, can we move this into ProfStef core? Then people > do > not have to work with a different interface and tutorials written for > ProfStef > will work exactly the same in the GUI browser. > > Danny > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 30, 2010

Re: [Pharo-project] Fun with ProfStef

by Danny Chan

Hi Dale > In putting together a couple of ProfStef tutorials last weekend, I found > that I'd like to be able to #goto a lesson (out of sequence), essentially > hitting a branch point where the student can skip a set of lessons or move > to a different set of lessons. My thought was something like: > > ProfStef goto: #lesson15 "jump to lesson15" We have now split the GUI changes I did into a separate package ProfStefBrowser. In this I have something like this ProfStefBrowser goto: SmalltalkSyntaxTutorial lessonAt: 3 This is used to replace the current lesson when I click in the tutorial tree. I just checked, and if I move three methods up the hierarchy, it works exactly the same in the ProfStef core. Laurent, if you like this, can we move this into ProfStef core? Then people do not have to work with a different interface and tutorials written for ProfStef will work exactly the same in the GUI browser. Danny

Jan. 30, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by StÃ©phane Ducasse

Thanks for the feedback. Stef On Jan 29, 2010, at 11:27 PM, Hernan Wilkinson wrote: > The changed you suggested worked on my machine, mac os X and also on a Debian. > > Hernan. > > 2010/1/28 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribiÃ³: > > I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. > > > > Bill > > > Yes, I know that the code is very difficult to understand, mainly > because of the primitives. They brake the understanding you have so far > when you have to switch to c code with a lot of pointers/structs/string > buffers. > > The problem here is that, now it is impossible to change the networks > subsystem of Pharo (or squeak). As Mariano said, we *need* to release > 1.0 and this bug can be a show stopper. > > Also, with due respect to the original coders of the network subsystem, > the code is really convoluted (I know that networking isn't simple), at > least to understand the fully implication of a "simple" change like > this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, > primitives and smalltalk code. So I think that is difficult to have > someone with the enough knowledge to change the code so that it works > for now. But that is how things are now. Maybe our own ignorance of the > code is what negates us a fix, but we need to left that apart and work a > solution for the *particular* problem in hand. For 1.1 we can discuss > new implementation if that is required. > > As Adrian said, there are users that need useOldNetwork true and some > others that need useOldNetwork to false. The problem is that we don't > fully understand the consequences of both changes. > > So, people, we need your help. Those who are most familiar with the > network code, please, please, take a look and suggest a solution for the > 1.0 release. *No* full rewrites, no throw code, no blaming, just a > working workaround for this. > > Regards > > Miguel Coba > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 30, 2010

Re: [Pharo-project] peek and friends

by Igor Stasenko

On 29 January 2010 23:09, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > hi Igor > > finally should I integrate > Â Â Â Â http://bugs.squeak.org/view.php?id=7446 ? > I was waiting because you said you were confused > Yes, integrate that, since it deals with issue that #peek should answer the same byte as following #next. We turned discussion into other issues, not related to this _bug_ (but related to #peek behavior), concerning what will happen if timeout appear. Here the last version(s) of both peek and next which taking care about it: !SocketStream methodsFor: 'stream in' stamp: 'Igor.Stasenko 1/15/2010 02:02'! next "Return next byte, if inBuffer is empty we recieve some more data and try again." [self isDataAvailable] whileFalse: [ self receiveData. self atEnd ifTrue: [ ^ nil ]]. ^inBuffer at: (lastRead := lastRead + 1) ! ! !SocketStream methodsFor: 'stream in' stamp: 'Igor.Stasenko 1/15/2010 01:33'! peek "Return next byte, if inBuffer is empty we recieve some more data and try again. Do not consume the byte." [self isDataAvailable] whileFalse: [ self receiveData. self atEnd ifTrue: [ ^ nil ]]. ^inBuffer at: lastRead +1! ! As you can see, the only difference between peek and next is that one advancing the buffer pointer, while other not. > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 30, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Miguel Enrique CobÃ¡ Martinez

El vie, 29-01-2010 a las 19:27 -0300, Hernan Wilkinson escribiÃ³: > The changed you suggested worked on my machine, mac os X and also on a > Debian. > Thank you for testing. I have only a Debian Squeeze machine and only tested there. But is good to know that works also in MacOS X. I am installing Windows 7 inside virtualbox to test in windows. Cheers > > Hernan. > > 2010/1/28 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K > escribiÃ³: > > I think you are correct about that being a bad change, but > there is more wrong than just that. There are IPv6-specific > calls that are not protected by subsequent tests on > #useOldNetwork. Further, the IPv6 code does not work > correctly, so many of us appear to need to override > #useOldNetwork to always return true. I make that change in > #useOldNetwork rather than #initialize. > > > > Bill > > > > Yes, I know that the code is very difficult to understand, > mainly > because of the primitives. They brake the understanding you > have so far > when you have to switch to c code with a lot of > pointers/structs/string > buffers. > > The problem here is that, now it is impossible to change the > networks > subsystem of Pharo (or squeak). As Mariano said, we *need* to > release > 1.0 and this bug can be a show stopper. > > Also, with due respect to the original coders of the network > subsystem, > the code is really convoluted (I know that networking isn't > simple), at > least to understand the fully implication of a "simple" change > like > this. It is not a well factored code. It mixes GUI prompts, > IPv4, IPv6, > primitives and smalltalk code. So I think that is difficult to > have > someone with the enough knowledge to change the code so that > it works > for now. But that is how things are now. Maybe our own > ignorance of the > code is what negates us a fix, but we need to left that apart > and work a > solution for the *particular* problem in hand. For 1.1 we can > discuss > new implementation if that is required. > > As Adrian said, there are users that need useOldNetwork true > and some > others that need useOldNetwork to false. The problem is that > we don't > fully understand the consequences of both changes. > > So, people, we need your help. Those who are most familiar > with the > network code, please, please, take a look and suggest a > solution for the > 1.0 release. *No* full rewrites, no throw code, no blaming, > just a > working workaround for this. > > Regards > > Miguel Coba > > -- > > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 29, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Schwab,Wilhelm K

The OS/vm is part of it; behavior also depends on whether the network is configured for ipv6, and perhaps whether or not it is done correctly. It gets complicated in a hurry. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Hernan Wilkinson [hernan.wilkinson(a)gmail.com] Sent: Friday, January 29, 2010 5:27 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? The changed you suggested worked on my machine, mac os X and also on a Debian. Hernan. 2010/1/28 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>> El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribiÃ³: > I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. > > Bill Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a "simple" change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 29, 2010