- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Remove developing with Pharo

by Andrei Stebakov

I created a chapter called "Remote Development" under the "Tips and Tricks" chapter. Here is the link: http://book.pharo-project.org/book/TipsAndTricks/RemoteDevelopment/?_s=q1YO… 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > Andrei: Once you have finished to make it work and how to tune it to make > it faster, it would be great if you can write this in a section/chaper of > the collaborative pharo book: http://book.pharo-project.org/ > > If you want I can creat you a user, and the section...then you only need to > write ;) > > > cheers > > mariano > > 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> > >> Ok, I figured it out. >> On the remote machine just start pharo with RFBServer started (connection >> passwords must be set!) >> On the local Windows machine open ssh or putty tunneling local port 5900 >> to the remote port 5900 (putty -L 5900:localhost:5900 username(a)doman.com >> ). >> After that start a VNC client (in my case I installed TightVNC) and >> connect to your local machine. >> That will automatically establish a tunneled traffic between those two >> systems va ssh tunneling. >> >> >> 2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> I paste a text I got from an old mail: "The latest version on >>> squeaksource works. You can load it from http://squeaksource.com/RFB(Note that this package has been forked at least three times.) We used to >>> connect to the server with RealVNC with the following settings: ZRLE >>> encoding (disable auto select), Full color. IIRC you should also turn >>> off the "render cursor locally" feature. >>> On the server you should allow ZRLE and turn off the conserve memory >>> feature. >>> " >>> >>> In addition, ask in seaside mailing list too. You will probably receive >>> more help. >>> >>> Cheers >>> >>> Mariano >>> >>> >>> >>> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> >>> >>>> Exactly what VNC slient I can use on Windows? >>>> I tried VNC viewer free ( >>>> http://www.realvnc.com/products/free/4.1/winvncviewer.html) trying to >>>> connect to the locally run Pharo and the viewer fails with "uncknown rect >>>> encoding" after which Pharo image also freezes. >>>> Is there any step-by-step tutorial how to setup VNC (remote Linux, local >>>> Windows)? >>>> >>>> >>>> On Thu, May 13, 2010 at 6:26 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com>: >>>>> > Interesting! Is it done on the X-server side or client? >>>>> > >>>>> you should have settings in your VNC client. >>>>> also, you could set bpp for image. >>>>> both could help to run things faster. >>>>> >>>>> > On Thu, May 13, 2010 at 5:38 PM, Igor Stasenko <siguctua(a)gmail.com> >>>>> wrote: >>>>> >> >>>>> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com>: >>>>> >> > That's right, looks like it sends full-blown images (not the >>>>> delta, not >>>>> >> > the >>>>> >> > commands to x-server) and re-drawing takes forever. I wonder if >>>>> it's a >>>>> >> > Pharo >>>>> >> > issue or x-server's? My xterm works pretty fast compared to Pharo >>>>> >> > though... >>>>> >> > >>>>> >> lowering the pixel depth to 8bpp helps :) >>>>> >> >>>>> >> > 2010/5/12 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>>> >> >> >>>>> >> >> I have at times done what you are attempting, and painful is >>>>> nicest >>>>> >> >> adjective I can think to use. Please let us know if VNC is a >>>>> better >>>>> >> >> option. Re RDP, I have wondered whether the poor performance >>>>> could be >>>>> >> >> telling us something about the amount of drawing that might be >>>>> >> >> happening for >>>>> >> >> no purpose??? It can be terribly slow, especially the response >>>>> to >>>>> >> >> typing. >>>>> >> >> Bill >>>>> >> >> >>>>> >> >> ________________________________ >>>>> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> >> >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf >>>>> Of >>>>> >> >> Mariano >>>>> >> >> Martinez Peck >>>>> >> >> Sent: Wednesday, May 12, 2010 10:25 AM >>>>> >> >> To: Pharo-project(a)lists.gforge.inria.fr >>>>> >> >> Subject: Re: [Pharo-project] Remove developing with Pharo >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com> >>>>> >> >>> >>>>> >> >>> Currently I have my web applications running on a Ubuntu box to >>>>> which >>>>> >> >>> I >>>>> >> >>> connect from a remote WinXP system via ssh. >>>>> >> >> >>>>> >> >> I guess the subject should be "remote" instead of "remove" ? ;) >>>>> >> >> >>>>> >> >> Sorry I ask but why not you cannot just develop in your pc and >>>>> with scp >>>>> >> >> or >>>>> >> >> similar you copy the .image and .image file trough ssh to the >>>>> server ? >>>>> >> >> >>>>> >> >>> >>>>> >> >>> My current set of tools is Lisp/Slime/Emacs. >>>>> >> >>> I tried to launch Pharo with X11 forwarding using X-server on >>>>> WinXP, >>>>> >> >>> but >>>>> >> >>> it painfully slow (the Pharo main windows redraws in a few >>>>> minutes). >>>>> >> >>> I am really thinking developing some web app using Pharo/Seaside >>>>> (I am >>>>> >> >>> liking the language more and more!) but I need to know to do it >>>>> >> >>> remotely via >>>>> >> >>> a secure connection. >>>>> >> >> >>>>> >> >> >>>>> >> >> Yes, there is an implementation of the VNC protocolol. You can >>>>> take a >>>>> >> >> Pharo image and load a VNC server. Then, you can connect to any >>>>> VNC >>>>> >> >> client >>>>> >> >> and what you see is the image....Then you can do whatever you >>>>> want. I >>>>> >> >> don't >>>>> >> >> know the performance, thus. >>>>> >> >> >>>>> >> >> That package is called RFB (remote something buffer) >>>>> >> >> >>>>> >> >> http://book.seaside.st/book/advanced/deployment/maintaining/vnc >>>>> >> >> >>>>> >> >> To install it: >>>>> >> >> >>>>> >> >> Gofer it >>>>> >> >> squeaksource: 'MetacelloRepository'; >>>>> >> >> package: 'ConfigurationOfRFB'; >>>>> >> >> load. >>>>> >> >> ((Smalltalk at: #ConfigurationOfRFB) project perform: >>>>> #latestVersion) >>>>> >> >> load. >>>>> >> >> >>>>> >> >> >>>>> >> >> Cheers >>>>> >> >> >>>>> >> >> Mariano >>>>> >> >> >>>>> >> >> >>>>> >> >>> >>>>> >> >>> Thank you, >>>>> >> >>> Andrei >>>>> >> >>> >>>>> >> >>> _______________________________________________ >>>>> >> >>> 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 >>>>> >> > >>>>> >> > >>>>> >> > _______________________________________________ >>>>> >> > 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 >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 >

May 20, 2010

Re: [Pharo-project] [squeak-dev] [BUG] LiteralVariableNode>>sizeCodeForStorePop:

by Eliot Miranda

Oops. Find fix attached: LiteralVariableNode methods for code generation (new scheme) sizeCodeForStorePop: encoder self reserve: encoder. ^(key isVariableBinding and: [key isSpecialWriteBinding]) ifTrue: [(self sizeCodeForStore: encoder) + encoder sizePop] ifFalse: [encoder sizeStorePopLiteralVar: index] Arguably the compiler should issue an error, but the error is raised at run-time because the generated code sends value: (correct) rather than using any of the store lit var bytecodes. If a compiler error is wanted (my preference) then find attached: LiteralVariableNode methods for testing assignmentCheck: encoder at: location ^(key isVariableBinding and: [key isSpecialWriteBinding]) ifTrue: [location] ifFalse: [-1] On Thu, May 20, 2010 at 2:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Open a browser, pick any class, and enter the code: > > foo > WorldState := nil > > then accept it. > The compiler goes into an infinite recursion in > LiteralVariableNode>>sizeCodeForStorePop:. > > sizeCodeForStorePop: encoder > self reserve: encoder. > ^(key isVariableBinding and: [key isSpecialWriteBinding]) > ifTrue: [(self sizeCodeForStorePop: encoder) + encoder > sizePop] > ifFalse: [encoder sizeStorePopLiteralVar: index] > > > (Pharo 1.1 having no such problem - it accepts a code without any > warnings.. ) > > AFAIK, it should either warn or throw an error that assignment is not > possible into read-only variable binding. > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 20, 2010

[Pharo-project] Need your opinion: What is most appealing form for GL function bindings?

by Igor Stasenko

There are multiple GL bindings exists by now - one that used by Croquet (FFI) - another one that using Alien and i doing one more, which using NativeBoost for callouts. And the question, what form of selectors you like most, pros/cons .. i need to know, because i can pick any of them, but i hope, that i will not be only one who using this stuff, so i need your opinion. Lets take a usual OpenGL function: void glVertex3f(GLfloat x, GLfloat y, GLfloat z) A Croquet/FFI bindings translates it to a following selector: 1. glVertex3f: x with: y with: z An Alien bindings using following form: 2. glVertex3fX: x y: y z: z Since my bindings will definitely use underscores, its not a problem to use a following one: 3. glVertex3f_x: x y: y z: z Currently i using this one: 4. glVertex3f: x y: y z: z In private mail with Andreas, he proposed a following: --- The one thing I'd consider is to use #comma: as the 'standard' keyword instead of #with: for example: 5. glVertex3f: x comma: y comma: z The reason should be obvious; you're replacing the comma so it should be a little more clear than using #with:. --- 6. this option actually not about positional arguments, but about omitting the 'gl' prefix for each function name. It is because, you already typing gl at each invocation: gl glVertex3f: x with: y with: z so, maybe it worth to omit gl prefix, so, a code will look like: gl Vertex3f: x with: y with: z (sure thing, one may use different name for api interface object, not 'gl'.. but i think that in 99.9% cases, 'gl' is a natural choice). --- My own choice is [3]. As to me, it helps greatly when you coding, so, once you autocomplete the selector, you know what parameter you need at each position, unlike anonymous keywords, like with: or comma: , which don't telling you anything about arguments you end up browsing docs each time. Oh, and btw, each time you need to change something, you again may need to refer to docs, since it still may be not clear, what argument types a function expects even if you look at already working code. The pro for picking [1] is mainly be compatible with lots of Croquet code which using GL. Except that, in NB bindings, i taking a constant names as is , i.e. GL_LINES, while croquet uses GLLines. So, its still will require porting. P.S. i'm already having some stuff working (see attachment).. But i little bit hesistant to do more, because then , if i reconsider about selector names, it will require a lot of fixes all around places. It generating all these methods automatically, so i can change a form at any moment. NBOpenGL methodDict size 2063 NBWgl methodDict size 132 NBGlx methodDict size 121 -- Best regards, Igor Stasenko AKA sig.

May 20, 2010

[Pharo-project] Community Development (a suggestion)

by Sean P. DeNigris

Since there is a major push in both Squeak and Pharo to be clear about what's loading where, and get more and more projects loadable; and the community is fixing projects that we don't own... I propose: 1. Everyone make your SqS repos globally writable unless you have a reason not to. 2. SqS admins, send an email to all the repo admins requesting this. Motivation: I've been fixing many projects as I try to load them, as a service to the community, but I am not necessarily taking on being responsible for their long-term maintenance. Right now, the process seems to be: 1. Upload fixes to my own repo 2. Email the project admin (if they are even still findable) 3. Post to the mailing lists with the new link 4. Wait for a response Not only is this more complicated than it has to be, but creates confusion. For example, I fixed ExternalWebBrowser to work in Pharo, but couldn't upload it to the project repo. Now I fixed the ConfigurationOf. Where do I put it? If I put it in the usual places, it will now point to my personal repository. It doesn't seem right to hijack someone else's project this way. And it's confusing for users - why are there two ExternalWebBrowsers and ConfigurationOfs on squeaksource? Thanks. Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224670.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

Re: [Pharo-project] MetaSource demo app working again

by Sean P. DeNigris

Mariano Martinez Peck wrote: > > Cool Torsten. I have just tested in Mac and I got a problem since > ExternalWebBrowserMacOS class >> isApplescriptAvailable uses SMSqueakMap > I had fixed this and made a new ConfigurationOf, but I don't have write access to the EWB repo, so they are both here: http://www.squeaksource.com/SPDProjectUpdates -- View this message in context: http://forum.world.st/MetaSource-demo-app-working-again-tp2223751p2224656.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

Re: [Pharo-project] inbox cleaning

by StÃ©phane Ducasse

Me tooooooooooo > > I sort of prefer: > SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) > That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inb

May 20, 2010

Re: [Pharo-project] Fwd: [Pharo-users] Accentuate Characters

by Henrik Johansen

On May 20, 2010, at 2:18 57PM, Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > From: Adrien BARREAU <abarreau.dev(a)live.fr> > Date: Mon, May 17, 2010 at 11:16 AM > Subject: [Pharo-users] Accentuate Characters > To: pharo-users(a)lists.gforge.inria.fr > > > Hello, > > I want to compose accentuate character in Pharo, but I don't know how I can do that. > I saw in Visual Works I can write this kind of things : > > $e composeDiacritical: (Character diacriticalNamed: #acute). > > That returns $Ã©. > > But, I don't find a way to do that in Pharo. > > Does somebody have an idea ? :) > > A.B. cc := CombinedChar new. cc add: $e; add: (Unicode value: 769); combined Diacriticals in CombinedChar only contain the Unicode Combining Diacritical Marks, it seems. There's no symbol -> diacriticial char mapping as far as I can tell. Cheers, Henry

May 20, 2010

Re: [Pharo-project] inbox cleaning

by laurent laffont

On Thu, May 20, 2010 at 3:17 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > FWIW, there's already kind of a process described at > http://code.google.com/p/pharo/wiki/HowToContribute > > I do agree with you on some things which could/should be changed though: > > On May 20, 2010, at 3:03 09PM, laurent laffont wrote: > > > I was thinking about following rules to make life easier: > > - a submission in PharoInbox must be a slice > +1. > Makes it much easier to scan the inbox for related package when an issue > has been marked as fixed and in Inbox. > Even when it only effects a single package (as the page states as an > exception to the slice-rule) > > > - slice must be formatted like LabelOfPatch-IssueNumber > > for example: > > BadCharactersInPackagenames-2124 > > PerformWithArgsPrimFailure-2443 > > - reject automatically slices which don't follow the name convention > > I sort of prefer: > SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) > That way all slices are next to each other in the inbox, and ordered by > number, which makes it much easier to find what you're looking for, either > when starting out with an issue from the bug tracker you need to integrate, > or when you're looking at which slices are in inbox, but need to know which > issues are safe to close. > Yes, better to have the number before. Maybe we can remove the word slice too: XYZM-DescriptionOfIssue. I think the real trick is to reject (kindly, with lot of explanations :) all slices which do not follow the adopted convention so people follow the rule. We can create a PharoRejected repository to let people know. Then some Smalltalk code scans PharoInbox, move bad formatted slices to PharoRejected automatically. In PharoRejected packages are deleted after 2 weeks for example. Laurent > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010

Re: [Pharo-project] halt in TTFontReader >>processCompositeGlyph:contours:from:

by Mariano Martinez Peck

2010/5/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > On May 20, 2010, at 2:11 48PM, Cyrille Delaunay wrote: > > Hello, > > There is a 'self halt' in the code of TTFontReader > >>processCompositeGlyph:contours:from:. > Therefore, when I try to import a font from a file, for example by > evaluating: > > TTFontDescription addFromTTFile: FileDirectory default fullName, > '/Fonts/DejaVu/DejaVuSans-Bold.ttf' > > the execution is stoped by this halt (And I don't know why). > Now, when I remove the 'self halt', all seems to work correctly. > > > The halt is in > > ((flags bitAnd: 2) = 2) ifFalse:[self halt]. > > From the spec at http://www.microsoft.com/typography/otspec/glyf.htm , > under Composite Glyph Description the flags are described : > * > * > ARGS_ARE_XY_VALUES1If this is set, the arguments are xy values; otherwise, > they are points. > So, it's probably an indication that reading the values as points is not > supported. > great. In such case we should write: ((flags bitAnd: 2) = 2) ifFalse:[self error: 'Reading the values as points is not supported']. :) Cheers Mariano > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010

Re: [Pharo-project] inbox cleaning

by Henrik Johansen

FWIW, there's already kind of a process described at http://code.google.com/p/pharo/wiki/HowToContribute I do agree with you on some things which could/should be changed though: On May 20, 2010, at 3:03 09PM, laurent laffont wrote: > I was thinking about following rules to make life easier: > - a submission in PharoInbox must be a slice +1. Makes it much easier to scan the inbox for related package when an issue has been marked as fixed and in Inbox. Even when it only effects a single package (as the page states as an exception to the slice-rule) > - slice must be formatted like LabelOfPatch-IssueNumber > for example: > BadCharactersInPackagenames-2124 > PerformWithArgsPrimFailure-2443 > - reject automatically slices which don't follow the name convention I sort of prefer: SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inbox, but need to know which issues are safe to close. Cheers, Henry

May 20, 2010