July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problem with streamsocket receiving

by Sven Van Caekenberghe

Kilon, I can't see any direct error in your code (on the client side, I don't known about the server). Consider this (do it): | stream | stream := SocketStream openConnectionToHostNamed: 'zn.stfx.eu' port: 80. stream sendCommand: 'GET / HTTP1.1', String crlf. stream upToEnd inspect . stream close. Client-side TCP is pretty simple. #sendCommand: does a #flush after adding a CRLF (we need two here). HTH, Sven PS: There is no need to do #isDataAvailable, reading a socket stream blocks while waiting for data (within the timeout). On 26 Jul 2014, at 01:04, kilon alios <kilon.alios(a)gmail.com> wrote: > so I have no issues sending data from pharo to python but I have a problem recieving data from python > > here is my method > > sendMessage: aString > > |stream errString isDataAvailable | > stream := SocketStream openConnectionToHostNamed: '127.0.0.1' port: 4000 . > stream sendCommand: aString. > isDataAvailable := stream isDataAvailable . > isDataAvailable inspect. > isDataAvailable ifTrue: [ errString := stream nextLineCrLf . > errString inspect. > errString = '' ifFalse: > [self error: errString.]] . > > stream close. > > > I have used telnet to test the connection , telnet can receive the data fine and it displays it fine. I have encode the data as bytestring from python with ascii encoding and added both a carriage return and a line feed in the end ? whats wrong ? > > I tried most method in socket stream even upToEnd message and none gives back any data. > > What am I doing wrong ?

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by Marcus Denker

On 26 Jul 2014, at 10:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 26 Jul 2014, at 09:58, stepharo <stepharo(a)free.fr> wrote: > >> >>> Slowly working on itâ¦ very early (and right now broken) stage is in the image. >>> And it is not yet decided how it will look like exactlyâ¦ the only thing clear is >>> that we need to use >>> >>> {#ivar1. #ivar2 . #boolean => BooleanSlot } >>> >>> instead of the stringsâ¦ both for ivars and class varsâ¦ I want to finish and debug the machinery around and then >>> start to play with it. >>> >>> I am a bit tempted to go the âbackward compatibleâ way and not use the term Slot but something like this: >>> >>> TestCase subclass: #RBProgramNodeTest >>> instanceVariables :{#ivar1. #ivar2 . #boolean => BooleanSlot } >>> classVariables: {#MyGlobal} >>> category: 'AST-Tests-Coreâ >>> >>> Ah, and we need to think about âcategoryââ¦ as we now have packages. >> >> You see how this is great not to have PoolDict in our face :) >> I would rename classVariables: into sharedVariables: and make them optional :) >> > I actually think shared variables is not goodâ¦ everyone talks about Class Variables > All Tutorials, all books. And it is very easy to confuse the term with Pools (I actually did so > when looking at the Class Builder). e.g. we would need to change the whole apiâ¦ now we have aClass classVariableNamed: âMyClassVarâ. would need to change to aClass sharedVariableNamed: âMyClassVarâ. and then: arenât Pool imported variables shared? So would this return a variable from a pool? if not, wouldnât that be confusing? Marcus

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by Marcus Denker

On 26 Jul 2014, at 10:02, stepharo <stepharo(a)free.fr> wrote: > Thierry we asked Mark Rizun to look into get a full "compilation unit" as an AST: > - AST for packages > - AST for class definition. > He should look at what gisela proposed and any feedback is interesting. > Only the name AST is wrong: the S stand for Syntax. There is no syntax for Classes, nor packages. What we want is models for everything with *the same API* as the nodes of the AST. (and visitors that can visit the whole structure) Marcus

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by Marcus Denker

On 26 Jul 2014, at 09:58, stepharo <stepharo(a)free.fr> wrote: > >> Slowly working on itâ¦ very early (and right now broken) stage is in the image. >> And it is not yet decided how it will look like exactlyâ¦ the only thing clear is >> that we need to use >> >> {#ivar1. #ivar2 . #boolean => BooleanSlot } >> >> instead of the stringsâ¦ both for ivars and class varsâ¦ I want to finish and debug the machinery around and then >> start to play with it. >> >> I am a bit tempted to go the âbackward compatibleâ way and not use the term Slot but something like this: >> >> TestCase subclass: #RBProgramNodeTest >> instanceVariables :{#ivar1. #ivar2 . #boolean => BooleanSlot } >> classVariables: {#MyGlobal} >> category: 'AST-Tests-Coreâ >> >> Ah, and we need to think about âcategoryââ¦ as we now have packages. > > You see how this is great not to have PoolDict in our face :) > I would rename classVariables: into sharedVariables: and make them optional :) > I actually think shared variables is not goodâ¦ everyone talks about Class Variables All Tutorials, all books. And it is very easy to confuse the term with Pools (I actually did so when looking at the Class Builder). Marcus

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by stepharo

Thierry we asked Mark Rizun to look into get a full "compilation unit" as an AST: - AST for packages - AST for class definition. He should look at what gisela proposed and any feedback is interesting. Stef

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by stepharo

> What I like with the #name=>Var notation is that it puts the name of the variable first. And it is just an expression > (you can evaluate it, itâs the same as BooleanSlot named: #boolean) yes this is nice.

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by stepharo

> Slowly working on itâ¦ very early (and right now broken) stage is in the image. > And it is not yet decided how it will look like exactlyâ¦ the only thing clear is > that we need to use > > {#ivar1. #ivar2 . #boolean => BooleanSlot } > > instead of the stringsâ¦ both for ivars and class varsâ¦ I want to finish and debug the machinery around and then > start to play with it. > > I am a bit tempted to go the âbackward compatibleâ way and not use the term Slot but something like this: > > TestCase subclass: #RBProgramNodeTest > instanceVariables :{#ivar1. #ivar2 . #boolean => BooleanSlot } > classVariables: {#MyGlobal} > category: 'AST-Tests-Coreâ > > Ah, and we need to think about âcategoryââ¦ as we now have packages. You see how this is great not to have PoolDict in our face :) I would rename classVariables: into sharedVariables: and make them optional :)

July 26, 2014

Re: [Pharo-dev] [Tip] Image init scripts when working with PharoLauncher

by stepharo

Thanks a lot. What I would like is that PharoLauncher does not get dizzy when I throw away a folder. And I would like it to detect the new folders I add. It could be done explicit (like Sync with DIsc) Stef On 25/7/14 13:54, Torsten Bergmann wrote: > PharoLauncher [1] allows you to work with many Pharo images. > > You can download fresh images, clone existing ones and with its access > to the Pharo CI it allows you to easily reproduce errors in specific Pharo > image versions. I REALLY like this tool when working with Pharo. > > There is a customizable hardware key on my laptop that I can just press > to open PharoLauncher, manage and launch the images and dive into the > world of Pharo. > > > To optimize my Pharo "easy access workflows" further I wanted all the > images that I started with PharoLauncher: > - to share a common metacello repository cache (where all the mcz > are stored independent from image location) for faster loading > - to have the possibility to preset the Squeaksource, SS3 and STHub password already > - to set my authors name > > All this is already explained in Marianos blog posts [2] and [3] and > the PharoEnterprise book [4]. > > Nonetheless I would like to share the script that I personally use. > Maybe (in an adopted version) it is usefull for other PharoLauncher > users as well: > > ===================================================================== > COMMON SETTINGS FOR ALL PHARO IMAGES WHEN STARTED USING PHAROLAUNCHER > ===================================================================== > Open any Pharo 3.0/4.0 image and execute > > StartupPreferencesLoader preferencesGeneralFolder fullName > > in a workspace to find out the common preferences folder on your > local machine. > > You can put a Smalltalk script into this folder, for instance > "initAllImages.st" that is evaluated each time an image runs. > > > I've found the following script very useful: > > ----------------------------------------------------------------- > | sharedPackageCacheDirectory | > "Never apply to PharoLauncher itself" > (SmalltalkImage current imageName includesSubstring: 'Launcher') ifTrue: [ ^self ]. > > "ask if script should be applied" > (UIManager default confirm: 'Apply init script from ', StartupPreferencesLoader preferencesGeneralFolder fullName,' to image') ifFalse: [^self ]. > > "Use a shared package cache to store Monticello MCS files for all images" > sharedPackageCacheDirectory := 'C:\Pharo\commonpackage-cache' asFileReference > ensureCreateDirectory; > yourself. > MCCacheRepository default directory: sharedPackageCacheDirectory. > > "Set password for Squeaksource" > (MCRepositoryGroup default repositories > select: [:each | (each isKindOf: MCHttpRepository) > and: [((each locationWithTrailingSlash includesSubstring: 'www.squeaksource.com') > or: [each locationWithTrailingSlash includesSubstring: 'http://ss3.gemstone.com/ss/'])] > ]) > do: [:each | each user: 'squeaksourceuser'; password: 'secretsqueaksourcepassword']. > > "Set password for SmalltalkHub (hub and HTTP repos)" > (MCRepositoryGroup default repositories > select: [:each | > (each isKindOf: MCSmalltalkhubRepository) and: [each locationWithTrailingSlash includesSubstring: 'smalltalkhub.com'] > ]) > do: [:each | each user: 'PharoUser'; password: 'sthubpassword']. > > (MCRepositoryGroup default repositories > select: [:each | > (each isKindOf: MCHttpRepository) and: [each locationWithTrailingSlash includesSubstring: 'smalltalkhub.com'] > ]) > do: [:each | each user: 'PharoUser'; password: 'sthubpassword']. > > "Set author name" > Author fullName: 'PharoUser'. > > UIManager default inform: 'Script applied'. > > ----------------------------------------------------------------- > > Hope it is usefull for others too. > > Bye > T. > > [1] http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher > [2] http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/ > [3] http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s… > [4] https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ws/Startup… > >

July 26, 2014

Re: [Pharo-dev] Returning the source of a class as a string

by Marcus Denker

On 26 Jul 2014, at 00:00, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 25/07/2014 23:46, Marcus Denker a Ã©crit : >> On 25 Jul 2014, at 23:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> On 25 Jul 2014, at 23:28, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>>> Le 25/07/2014 23:15, Marcus Denker a Ã©crit : >>>>> On 25 Jul 2014, at 21:51, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>>> Le 25/07/2014 21:42, kilon alios a Ã©crit : >>>>>>> ok we are getting somewhere, the problem is that if I do >>>>>>> >>>>>>> (SomeClass compiledMethodAt: #nameOfMethod it will look only in the instance side for method, how I look also for class methods ? Also how I can return source of class ? to be specific I need the names of instance variables, class variables and class instance variables . >>>>>> For the class method: >>>>>> >>>>>> SomeClass class compiledMethodAt: #nameOfClassMethod >>>>>> >>>>>> For the instance variable, etc... SomeClass definition will give you that. But it's a bit tricky to parse; for example, if you want a reification (instance variable name is recognized as instance variable name in the ast), I have some code which does: parse, rewrite and reparse on a class definition (for the smart suggestion thing). >>>>>> >>>>> Yes, we need thatâ¦ >>>>> there is code on the issue tracker, too: >>>>> >>>>> https://pharo.fogbugz.com/f/cases/10983/Represent-a-class-definition-with-A… >>>> Yes. What about the class definition format change described by Camillo? >>> Slowly working on itâ¦ very early (and right now broken) stage is in the image. >>> And it is not yet decided how it will look like exactlyâ¦ the only thing clear is >>> that we need to use >>> >>> {#ivar1. #ivar2 . #boolean => BooleanSlot } >>> >>> instead of the stringsâ¦ both for ivars and class varsâ¦ I want to finish and debug the machinery around and then >>> start to play with it. >>> >>> I am a bit tempted to go the âbackward compatibleâ way and not use the term Slot but something like this: >>> >>> TestCase subclass: #RBProgramNodeTest >>> instanceVariables :{#ivar1. #ivar2 . #boolean => BooleanSlot } >>> classVariables: {#MyGlobal} >>> category: 'AST-Tests-Coreâ > I'd be tempted not to write an adhoc mini-language inside the instanceVariables array. Why not just something like: > What I like with the #name=>Var notation is that it puts the name of the variable first. And it is just an expression (you can evaluate it, itâs the same as BooleanSlot named: #boolean) So it is just an expession, and e.g. classes could create slots: {Integer typedSlotNamed: #i} > If you want the grand show, I'll make you a wizard for creating classes with at least 10 steps ;) >>> >>> Ah, and we need to think about âcategoryââ¦ as we now have packages. >>> >> But for the âwe need some kind of AST like structureâ it changes nothing: this is still a message send, >> but we need to reason about a class definition if we want to have suggestions (and with them e.g. BreakPoints >> on variables) working. >> >> Marcus >> > I have that working without a real "ClassDefinition node" at the moment. Really very convenient to have the refactorings on instance variables working straight out of the class description text pane by just selecting the instance variable name in the string. > > Class definitions are either normal messages (for example in code creating a class by hand) or descriptions visible in browsers (interactive use). > > In the first case, you should not interpret them as class definitions since the class may/probably does not exist at that point. It is then just a message. > > In the second case, the GUI can ask for interpretation of the message into a class definition. I think this is how Gisela solution works, no? > Yes! Marcus

July 26, 2014

Re: [Pharo-dev] Does anyone use menuMorph in dockingbar?

by Chris Muller

Those are Flaps, not DockingBars. On Fri, Jul 25, 2014 at 12:48 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Isn't DockingBar a Squeak thing? The little tabs things that would live > around the edges of the screen and you could grab morphs onto a canvas. > > > On Fri, Jul 25, 2014 at 2:06 AM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> No idea what this could be. >> go go go! >> >> Alexandre >> >> >> On Jul 24, 2014, at 4:39 PM, stepharo <stepharo(a)free.fr> wrote: >> >> > Hi guys >> > >> > the code of MenuMorph is crippled of isInDockingBar and the logic is >> much more complex. >> > I have the impression that it is decades since we got a menu in a >> docking bar. I do not even remember >> > what it mean. I would like to clean this part because we should really >> be a bit more radical else we will die under >> > the mass of complex, old.... code. >> > >> > Stef >> > >> > looks like a dockingbar is this >> > >> > DockingBarMorph new >> > addMorph: (SimpleButtonMorph new >> > label: 'Say hello'; >> > target: [UIManager inform: >> 'Hello']; >> > actionSelector: #value); >> > addMorph: (SimpleButtonMorph new >> > label: 'Say bonjour'; >> > target: [UIManager inform: >> 'Bonjour']; >> > actionSelector: #value); >> > addMorph: (SimpleButtonMorph new >> > label: 'Close'; >> > target: [DockingBarMorph >> allInstances last delete]; >> > actionSelector: #value); >> > adhereToBottom; >> > openInWorld. >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >

July 25, 2014