- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] SqueakSource AND SmalltalkHub down ;)

by Serge Stinckwich

Maybe, you should put a nice page when the server is down. On Wed, Apr 20, 2011 at 4:43 PM, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: > Le mercredi 20 avril 2011 Ã 11:30 +0200, Torsten Bergmann a Ã©crit : >> >SqueakSource AND SmalltalkHub down >> >> Yes, it looks like SmalltalkHub replaces all features >> of squeaksource and mimicks also the down behavior ;) > Hehe :-) > I shutdown the demo of SmalltalkHub because of some issues we got, > especially a (stupid) security hole. > > I'll let you know when it will be back online. > > Cheers, > Nicolas > >> >> >Btw: anyone eager to try out >> >SqueakSource3 ? >> >It is available as and alpha Metacello Config. >> >> Does it work with Pharo 1.2 already? Could you post >> a script for people to load and try? >> >> Thx >> T. > > -- > Nicolas Petton > http://www.nicolas-petton.fr > > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 21, 2011

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

by Casey Ransberger

More recently, he said "Smalltalk: Welcome to the Balkans." On Apr 20, 2011, at 7:01 PM, Reg Krock <rkrock3(a)yahoo.ca> wrote: > I think it was Kent Beck who ended his email with: "Source code in files? How 1970ish" > > Reg > > On 2011-04-20, at 4:17 PM, Norbert Hartl wrote: > >> Amen! >> >> Norbert >> >> Am 20.04.2011 um 18:01 schrieb Dale Henrichs: >> >>> 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 Reg Krock

I think it was Kent Beck who ended his email with: "Source code in files? How 1970ish" Reg On 2011-04-20, at 4:17 PM, Norbert Hartl wrote: > Amen! > > Norbert > > Am 20.04.2011 um 18:01 schrieb Dale Henrichs: > >> 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 GermÃ¡n Arduino

2011/4/20 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Next thing, let we rather start integrating different Smalltalk code on > all our dialects first and using SmalltalkHub for socializing in > Smalltalk community as a whole. First, and before socializing with > others! Here SmalltalkHub again promise a lot and we can actually > achieve a goal of *one*, only one entry point to *all* Smalltalk code, > in *all* dialects! > This is an interesting point also. Would be nice to have some sort of common things between all the smalltalks.

April 20, 2011