April 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.2] #12349

by Marcus Denker

12349 ----- Issue 1853: NetNameResolver localHostAddress returns public or private address instead of loopback address. Issue 3996: alt+k opens a StringHolder and not a workspace Next for 1.2.2: -> fix build 1.2 -> integrate Lukas' OB -> release. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 21, 2011

Re: [Pharo-project] Networking problems on Pharo 1.2.1

by Luc Fabresse

Hi, Yes SocketStream is useful but still, the socket base layer should be usable without problems ... I do not know why #waitForAcceptFor: do not make it. #Luc 2011/4/21 GÃ¶ran Krampe <goran(a)krampe.se> > On 04/21/2011 07:17 AM, Oscar E A Callau wrote: > >> Hi again, >> >> I found a solution (but not what was the problem); change the server code >> to the following: >> > > Just a tip: Please use SocketStream, it will help you when doing the actual > sending/receiving. In almost every situation SocketStream is your friend. > > regards, GÃ¶ran > >

April 21, 2011

Re: [Pharo-project] Networking problems on Pharo 1.2.1

by GÃ¶ran Krampe

On 04/21/2011 07:17 AM, Oscar E A Callau wrote: > Hi again, > > I found a solution (but not what was the problem); change the server code to the following: Just a tip: Please use SocketStream, it will help you when doing the actual sending/receiving. In almost every situation SocketStream is your friend. regards, GÃ¶ran

April 21, 2011

[Pharo-project] Fwd: update needed to Pharo book section 3.5

by laurent laffont

If someone can look at this .... Laurent ---------- Forwarded message ---------- From: Doug Edmunds <dougedmunds(a)gmail.com> Date: Mon, Apr 18, 2011 at 11:40 PM Subject: update needed to Pharo book section 3.5 To: laurent laffont <laurent.laffont(a)gmail.com> http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting uses ParagraphEditor in the example code. According to v 1.3, ParagraphEditor is deprecated (Deprecated13 package). You should hunt around for some other class to use in section 3.5 instead of ParagraphEditor. :dae

April 21, 2011

Re: [Pharo-project] Networking problems on Pharo 1.2.1

by Oscar E A Callau

Hi again, I found a solution (but not what was the problem); change the server code to the following: |port msg| port:= 9191. Transcript open; show: 'testing --- ' ; cr. listening := true. [self isListening] whileTrue: [ |server connectedClient| server := Socket newTCP. server listenOn: port. connectedClient := [server waitForConnectionFor: 5] on: ConnectionTimedOut do: [] . server isConnected ifTrue: [ msg:= 'Data: ', server receiveData. Transcript show: msg ; cr. ]. server closeAndDestroy. ]. Transcript show: 'end ------'. basically, I'm changing #waitForAcceptFor: for #waitForConnectionFor: I hope someone can explain me what are the differences. Cheers On Apr 20, 2011, at 23:20 , Oscar E A Callau wrote: > Hi all, may be this is a simple/stupid/repetitive question, but I don't know how to solve it. > > I'm trying to connect two sockets on Pharo 1.2.1, with following code: > > Server > -------- > > |port msg| > port:= 9191. > > Transcript open; show: 'testing --- ' ; cr. > > listening := true. > [self isListening] whileTrue: [ > |server connectedClient| > server := Socket newTCP. > server listenOn: port. > connectedClient := server waitForAcceptFor: 5. > connectedClient ifNil: [msg:='TimeOut'] ifNotNil:[ > msg := 'Data: ', connectedClient receiveData > connectedClient closeAndDestroy ]. > Transcript show: msg ; cr. > server closeAndDestroy. > ]. > > Transcript show: 'end ------'. > > > ------------ > Client > ------------ > > | s | > s:= Socket newTCP. > s connectToHostNamed: 'localhost' port: 9191. > s sendData: 'Hello'. > s closeAndDestroy > > > --------- > > First I run the server and later the client and get the following error: > > Error: primAcceptFrom:receiveBufferSize:sendBufSize:semaIndex: failed > > I attach a screenshot of the debug window. > > > Thanks in advance. > > <Screen shot 2011-04-20 at 23.16.48 .png>

April 21, 2011

[Pharo-project] Networking problems on Pharo 1.2.1

by Oscar E A Callau

Hi all, may be this is a simple/stupid/repetitive question, but I don't know how to solve it. I'm trying to connect two sockets on Pharo 1.2.1, with following code: Server -------- |port msg| port:= 9191. Transcript open; show: 'testing --- ' ; cr. listening := true. [self isListening] whileTrue: [ |server connectedClient| server := Socket newTCP. server listenOn: port. connectedClient := server waitForAcceptFor: 5. connectedClient ifNil: [msg:='TimeOut'] ifNotNil:[ msg := 'Data: ', connectedClient receiveData connectedClient closeAndDestroy ]. Transcript show: msg ; cr. server closeAndDestroy. ]. Transcript show: 'end ------'. ------------ Client ------------ | s | s:= Socket newTCP. s connectToHostNamed: 'localhost' port: 9191. s sendData: 'Hello'. s closeAndDestroy --------- First I run the server and later the client and get the following error: Error: primAcceptFrom:receiveBufferSize:sendBufSize:semaIndex: failed I attach a screenshot of the debug window. Thanks in advance.

April 21, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Steven Baker

>> A thing I not understand is why we need to go "file-based" if we are >> already object based (several steps ahead)? > > The folks that would like to see Smalltalk be more file-based have very good points ... Smalltalk would be more accessible to other developers, it would be easier for folks to learn Smalltalk if they didn't have to learn new tools along with a new language, etc.... They already have GNU Smalltalk. GNU Smalltalk is a nice in-between for this. I find I lose a lot, though. > So it would be really nice if we could keep our object orientation while providing a development environment that was familiar to developers from other languages .... > > we'd have our cake and eat it too:) > >> >> >> >>> Until then, long live SqueakSource3 and SmalltalkHub:) >>> >> >> Sure! But, (I'm only asking) we couldn't using Git with objects? It's >> only curiosity, not that I would like Git, eheh, I knew Github only >> today! > > At the moment I don't think that a transition to to Git would be transparent ... If it were that easy, I would think that it would be done by now:). Not only that, but by storing Smalltalk code in Git, we'd lose most of the features that you want from version control anyways, since Git tools only work with text files. -Steven

April 21, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Steven Baker

Thank you! It bothers me slightly that we're actually having this discussion. Trying to divorce Smalltalk from the image loses a great deal of flexibility that we have all come to know and love. Divorcing Smalltalk from the image so we can use great tools might be a reasonable thing to do, but Git is not a great tool. -Steven On 2011-04-20, at 11:15 AM, Dale Henrichs wrote: > Camillo, > > I understand that folks don't understand why Smalltalkers "don't just start using files like everyone else". I have tried to explain ... it is not arrogance nor ignorance. The image is the difference ... > > The image makes it possible for developers to debug and explore the "live object model" in the image ... it is what makes me productive ... I don't care about the syntax either... > > As a Smalltalker I need to _make changes to the source code in a live image_ and when I make those changes I need to be able to manage the changes I make in some sort of source code management system... that's why change sets were invented and you can read the rest of the story below... > > Smalltalkers don't use the traditional tools, because the traditional tools aren't designed to work with Smalltalk images ... it's not arrogance ... the Smaltalk tools operate on the image not a set of files ... > > It's a different paradigm, so Smalltalkers aren't reinventing the wheel, they are building a wheel that rolls in the image... > > Dale > > On Apr 20, 2011, at 9:51 AM, Camillo Bruni wrote: > >> Objection! ;) >> >> Using git has nothing to do with a file based system. The approach would be to use git as a storage backend for monticello. Git just stores 3 types of objects: commit, tree, blob. >> There are no files involved!! So this would be perfectly compatible with and image based system such as smalltalk. >> >> see: http://book.git-scm.com/1_the_git_object_model.html >> >> >> personal rant from here on >>> >> >> However I see that smalltalkers tend to ignore the fact that there are other tools not written in smalltalk which are widely used and they actually work! For instance monticello. Although the model works perfectly fine, the UI is just plain crap, it does not provide a nice workflow nor is it readable... Git on the other hand might be too complex, but it lets do more stuff on the command line, in an easier fashion than the mc tool. >> >> Smalltalkers tend to reinvent the wheel, which is sometimes nice, if its well designed and actually works, but many times its rather a waste of time, than just relying on existing working infrastructure that people outside smalltalk build. >> >> What I see in Pharo is a good move towards making these tools work again, most of them are just old and ignore common UI principles. >> >> >> And Smalltalk is not the holy grail, its just yet another programming language, which has nice syntax ;). >> >> >> On 2011-04-20, at 18:10, Serge Stinckwich wrote: >>> Even if SmalltalkHub looks like GitHub, its still based on Monticello. >>> Another aspect also important in github and similar tools is social coding. >>> This is very easy to follow your favorite developpers and to >>> participate by cloning his/her repository. >>> >>> Regards >>> >>> On Wed, Apr 20, 2011 at 11:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>> Smalltalk is not file-based. For better or for worse. >>>> >>>> The fundamental problem with Smalltalk is that it is image-based. >>>> >>>> Removing a method from a file is not sufficient to remove the method from the image. >>>> >>>> Change sets were invented to provide a file-based solution to the "how do I remove a method from the image" problem. >>>> >>>> A filein (the one used to initialize your image) plus a series of change sets applied in the right order is the file-based methodology for managing an image. >>>> >>>> Change sets are integral to Smalltalk. >>>> >>>> Name another language that uses change sets ... >>>> >>>> I cannot distribute a fresh set of source files to _upgrade_ an already installed application. I have to supply change sets and those change sets have to specific to the version that is installed in the image ... >>>> >>>> Remember the problem is "how do I remove a method from the image". >>>> >>>> The image is a data base, not an executable program, when you load code you also migrate/modify the objects in your "data base". >>>> >>>> Name another language that does this.... >>>> >>>> Monticello was invented along the way ... I cannot speak to the original motivation, but I can say that with Monticello I _can_ distribute a fresh set of source files to _upgrade_ an already installed application. >>>> >>>> Monticello does this by having a meta model that describes the complete application. The meta model is not a "source file" it is a serialized object graph. >>>> >>>> Monticello dynamically creates a change set by comparing the meta model of the loaded application with the meta model of the incoming "source code". >>>> >>>> Name another language that does this.... >>>> >>>> So the meat and potatoes of a Monticello mcz file is a binary chunk of data.... >>>> >>>> What does git do with binary data? What do humans do with binary data? >>>> >>>> You need a tool that takes the binary data and makes it readable for the poor developers who cannot unzip and deserialize a binary stream of bits on sight. >>>> >>>> Enter SqueakSource and SmalltalkHub.... >>>> >>>> This is where we are today. >>>> >>>> Can Smalltalk development be based on files....certainly everyone was doing file-based development in 1985, but the Smalltalk environments of the day migrated away from files ... >>>> >>>> In 1985 I was writing tools to store files and change sets in RCS ... the original ChangeSorter was based on my work back then... >>>> >>>> In 1993 I was working on tools that stored Smalltalk source meta data using PKZIP ... >>>> >>>> ENVY stores source meta data into a custom data base.... >>>> >>>> Store stores source meta data in an RDB... >>>> >>>> In 2011 I am working on tools that store Smalltalk source meta data using zip ... >>>> >>>> Smalltalk is image-base and the "standard" development tools just don't fit ... for better or for worse ... >>>> >>>> Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. >>>> >>>> Just because 20 years of evolution has moved Smalltalk away from using files in the traditional manner, doesn't mean that it won't evolve back to using files, but until the evolution happens, we need tools like SqueakSource3 and SmalltalkHub to support the _current_ model. >>>> >>>> Dale >> >> >> > >

April 21, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Steven Baker

> Using git has nothing to do with a file based system. The approach would be to use git as a storage backend for monticello. Git just stores 3 types of objects: commit, tree, blob. > There are no files involved!! So this would be perfectly compatible with and image based system such as smalltalk. Agreed. Git can easily be used as a storage system for our tools. > > However I see that smalltalkers tend to ignore the fact that there are other tools not written in smalltalk which are widely used and they actually work! For instance monticello. Although the model works perfectly fine, the UI is just plain crap, it does not provide a nice workflow nor is it readable... Git on the other hand might be too complex, but it lets do more stuff on the command line, in an easier fashion than the mc tool. Monticello may have a poor UI, but Git has the worst possible UI, encourages awful practices, and just doesn't do the job well. Can we stop making this about Git, and actually make it about solving real problems? The real problems, as I see them, are: 1) We would like good UIs for interacting with our version control system, and 2) We would like an online tool for collaboration and sharing. Neither of these problems are solved by Git, so I would ask that people stop talking about Git as though it solves either one of them. GitHub solves the latter, an lots of the former, and perhaps that's where we should start looking. > Smalltalkers tend to reinvent the wheel, which is sometimes nice, if its well designed and actually works, but many times its rather a waste of time, than just relying on existing working infrastructure that people outside smalltalk build. I disagree here; version control is an invaluable part of development, it should be part of the environment. How is using a system that is older than Git (Monticello) reinventing the wheel? -Steven

April 21, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Steven Baker

> > Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. First: anyone complaining that we can't use git, hasn't used great version control tools. I think what people want is GitHub, which is great. We can have GitHub and base it on Monticello. And I'm happy to work on this. But not alone. -Steven

April 21, 2011