- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2756: Morphic Cleansing - Remove use of findA:

by Guillermo Polito

Hi! I realized that because *Morphic>>findA: aClass "Return the first submorph of the receiver that is descended from the given class. Return nil if there is no such submorph. Clients of this code should always check for a nil return value so that the code will be robust if the user takes the morph apart." ^self submorphs detect: [:p | p isKindOf: aClass] ifNone: [nil]* we can simply replace MenuMorph>>doButtonAction by *MenuMorph>>doButtonAction "Do the receiver's inherent button action. A MenuMorph that is a wrapper for a single menu-item -- pass it on the the item. We should enhance or think what to do with a MenuMorph with multiple items" self menuItems notEmpty ifTrue:[ self menuItems first doActionButton ]* I'll look at that a few minutes to give a little fix :). On Fri, Aug 6, 2010 at 6:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Aug 6, 2010, at 4:54 AM, Guillermo Polito wrote: > > > Hi, removing some findA: message sendings > > Yes yes yes!!! > We only need a few of them. > > > i've found: > > > > MenuMorph>>doButtonAction > > "Do the receiver's inherent button action. Makes sense for the kind > of MenuMorph that is a wrapper for a single menu-item -- pass it on the the > item" > > > > (self findA: MenuItemMorph) ifNotNil: [:aMenuItem | aMenuItem > doButtonAction] > > > > > > And for me it doesn't make sense :). Even the comment doesn't make > sense, because it isn't considering the case where a MenuMorph has multiple > MenuItemMorph s. > > > > What should be done in cases like that? If it's my code, i should be > tempted to delete it or maybe to deprecate it. And I'm really upset because > it is a very difficult thing to verify not to break too much other things. > So, what is the "official policy" about this cases? :P I don't like to > leave it as it is... > > Get one or more scenario where the code behavior normally > and rewrite so that it does not use findA: > What I suggest is that you start with the easy findA: and publish often so > that we integrate them in the system > and slowly we learn and fix the ugly. > > Stef > > > > > > > Cheers, > > Guille > > _______________________________________________ > > 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 >

Aug. 7, 2010

Re: [Pharo-project] Question: How can I add a items to System Browser Window menu?

by Guillermo Polito

I think Car meant the context menu when you right-clic a category in the System Browser. I don't know how, but maybe my screenshot help someone to help you :). On Sat, Aug 7, 2010 at 8:11 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > > On Aug 7, 2010, at 12:22 PM, Carla F. Griggio wrote: > > > Hello! > > > > I want to add an item to the menu that appears when you right click on a > category in the System Browser window. > > > > I think that menu is built here: > > > > Morph>>buildMetaMenu: evt > > > > But I don't want to touch that method, not SystemWindow>>buildMetaMenu: > evt either, because that option would have to be visible only if my project > has been loaded. > > exactly nobody should change the core methods just declare intention. > > > > Is there a way to do that? > > sure. > you should use a pragma <menu> > > here is for example how this is done for ScriptLoader > > menuCommandOn: aBuilder > <worldMenu> > > (aBuilder item: #'Integrator Menu') > order: 1.5; > precondition: [self currentlyIntegratingChanges]; > parent: #System; > action: [ScriptLoader releaseMenu] > > > > > > > Thanks! > > Carla > > _______________________________________________ > > 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 >

Aug. 7, 2010

Re: [Pharo-project] Instance variable pull up broken

by Lukas Renggli

I cannot reproduce. If you look at the code you should see that what you describe should not happen: transform class allSubclasses do: [:each | (each directlyDefinesInstanceVariable: variableName) ifTrue: [each removeInstanceVariable: variableName]]. class addInstanceVariable: variableName Maybe your class hierarchy is broken? Lukas On 7 August 2010 22:18, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > Here's a funny way to crash your image. Works in: > > Pharo-1.1-11367-Beta > Latest update: #11367 > > Make a class named AbstractBla, with two subclasses: SubA, SubB. Then, > add to both SubA and SubB the identically named instance variable: > instVar. Now, use the "pull up" refactoring in OmniBrowser on SubA to > pull up instVar into the superclass. As you correctly guess, that > breaks SubB, because now both its superclass and SubB have an instance > variable named instVar. But, instead of refusing to refactor, > OmniBrowser dutifully refactors and takes the image with it. > > I hope that was understandable. > > Cheers, > > Niko > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Aug. 7, 2010

[Pharo-project] Instance variable pull up broken

by Niko Schwarz

Here's a funny way to crash your image. Works in: Pharo-1.1-11367-Beta Latest update: #11367 Make a class named AbstractBla, with two subclasses: SubA, SubB. Then, add to both SubA and SubB the identically named instance variable: instVar. Now, use the "pull up" refactoring in OmniBrowser on SubA to pull up instVar into the superclass. As you correctly guess, that breaks SubB, because now both its superclass and SubB have an instance variable named instVar. But, instead of refusing to refactor, OmniBrowser dutifully refactors and takes the image with it. I hope that was understandable. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Aug. 7, 2010

Re: [Pharo-project] XML Parser, Monticello and unicode?

by Philippe Marschall

On 07.08.2010 13:08, Norbert Hartl wrote: > .... > To estimate the possibility to change this I think we should fix this. I scanned all of my cached monticello packages. Most of them are 7bit clean. No problem for them if we change encoding. Besides XML Parser I didn't find any that contain WideString so no problem here. Some of them are latin1 encoded (like Seaside 2.8 or Seaside-InternetExplorer from 3.0). That is the biggest problem because there is no fallback and monticello does not have a version number on file format, right? > I think it is still feasible to change this in monticello as the fix for users of older images will be probably only a few lines that you can apply to any version of monticello if I'm not wrong. But the change is not that easy. We try to be 7bit clean in Seaside. Can you report the methods you have trouble with to either the seaside mailing list or the issue tracker [1]? [1] http://code.google.com/p/seaside/issues/list Cheers Philippe

Aug. 7, 2010

Re: [Pharo-project] TextMorph without being able to be edited?

by Schwab,Wilhelm K

Carla, It's not silly when you can't figure out how to do it. Just glancing at some of my code, I think one approach is to use #newTextEditorFor:getText:setText:. The receiver is a TEasilyThemed user (StandardWindow is a good example). The first argument is the model, and the last two are selectors for message the model should understand. Give nil for the setter, and I *think* you will get what you want. If not, there will be some type of read-only flag to be set. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Carla F. Griggio [carla.griggio(a)gmail.com] Sent: Saturday, August 07, 2010 6:26 AM To: Pharo Development Subject: [Pharo-project] TextMorph without being able to be edited? Hi again, everyone! I think this might be really really silly, but I couldn't find a way to show a TextMorph without the ability to edit it's text. If I use a StringMorph to show a paragraph, it looks horrible, but if I use a TextMorph and click on it, a blue border appears and I'm able to edit the text, I don't want that to happen. Is there another morph for showing text that only shows text and nothing else? Or a property of TextMorph that I'm missing? Thanks! Carla

Aug. 7, 2010

[Pharo-project] Polymorph composites

by Schwab,Wilhelm K

Hello, With no small push from Andreas (and Pharo in general), I have been able to build something that is pretty much exactly what I envisioned. That attached has some identifiers blocked out but hopefully conveys what I am trying to do. The draw/erase and square/circle buttons do what you would expect, and apply to a monochrome mask that is represented by the dotted pattern. The next step is to integrate this into a larger shell, and this is where either I have something to learn of Polymorph has room to grow. What you see should be (in Dolphin parlance) a CompositePresenter that can readily be embedded in other morphs/presenters/whatever-we-call-them. As it is, I get a jumbled mess unless I create this in a system or standard window :( The images naturally come in three interlaced sequences of pairs. It would be very natural to show multiple instances of this composite structure. Is there a way to re-use it w/o a shell? Bill

Aug. 7, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Schwab,Wilhelm K

Stef, Great news about the sockets rewrite!! On my wish list includes OpenSSL (Andreas appears to be making strides there??) and to see the end of polling for connections. Ideally, one could set the type of socket to be either TCP, UDP (for those who must), IrDA, etc. and have it work. It would also be nice to be able to get events when the other side closes the connection. Good network programming requires good error handling, and asynchronous activity. One must be able to reboot peers, turn off hubs, yank wires (name it) and not have the software hang. I don't think I care whether that is done with asynch sockets or blocking ones called on OS threads, but we're not done until it "never" hangs. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, August 07, 2010 10:50 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Poll: missing libraries to support business On Aug 7, 2010, at 2:00 PM, Philippe Marschall wrote: > On 02.08.2010 21:50, StÃ©phane Ducasse wrote: >> Hi guys >> >> with the experience around the XMLRPC project, ESUG wants to change strategy to help growing business at the technical >> level. So what are the key areas where you think that effort should be supported to help you making business in smalltalk? > > Rather than imagining what problems non-users could have I'd focus on > what problems existing users have. Instead of building libraries that > you'll have to maintain forever I'd focus in infrastructure that allows > users to write the libraries they need themselves. Yes! But a poll is interesting. > Executive summary: > - HTTP(S) > - SqueakDBX > - VM/Cog/kernel/FFI/Alien The last line is really into our radar and our engineer will make sure FFI/Alien will work 100% Noury and luc really need sockets and started to rewrite them using Alien and this something that we want to push too. > Something that always comes up is a usable HTTP client that does HTTPS, > proxies, authentication, multipart, not have to load the entire > response/request into memory, probably even keep-alive. WebClient could > be the solution here once you have documentation, examples and don't > need an override on String >> #,. As more and more things are HTTP based > these days having a good HTTP story is important. Again WebClient has an > advantage here because it answers both the client and the server part. > NTLMv2 would be awesome but may not be possible. For WebClient this is good that andreas started to clean that part we really want to support that effort and this was also in our radar > What also seems to come up frequently is relational databases. I have > already meat people who told me "I would use Squeak/Pharo over dialect X > if only I could connect to Oracle". Having a common interface for > relational databases despite all the "NoSQL" hype is important even if > it requires installing native (C) client libraries. SqueakDBX seems to > be the only option here right now. this is why ESUG supported this project over the years. > And finally having a fast and stable kernel and runtime including > Sockets/Semaphores/weak array finalization. That includes helping Eliot > to make Cog a replacement for the current VM. That includes having a > prebuilt Coq VM available with warning signs. That includes having an > easy way to bind C libraries without writing a plugin. See above. Yes > That includes > non-blocking FFI calls. That may include having a way to do > sendfile()/TransmitFile() on sockets. That may include instead of having > Semaphore, Mutex and Monitor only having the class that you're supposed > to use. That may include a ReadWriteLock. I do not know :) but we will know it soon (by january or february) > > Cheers > Philippe > > > _______________________________________________ > 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

Aug. 7, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Andrei Stebakov

Yes, that's correct for Set-cookie (the response), each has its own line. "Cookies: " for request should be all in one line. On Sat, Aug 7, 2010 at 8:05 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 04.08.2010 19:15, Andreas Raab wrote: >> On 8/4/2010 9:57 AM, Mariano Martinez Peck wrote: >>> Hi Adrei, excellent :) >>> >>> BTW, for HTTP Client you should cc Andreas Raab Â or squeak mailing >>> list.... >> >> Squeak-dev please >> (http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev) >> >>> On Wed, Aug 4, 2010 at 6:08 PM, Andrei Stebakov <lispercat(a)gmail.com >>> <mailto:lispercat@gmail.com>> wrote: >>> >>> Â Â I also found that cookies were not correctly sent. >>> Â Â Every cookie was sent with its own "Cookie: " header which is not >>> Â Â correct. >> >> I'm curious, why do you think that's incorrect? My understanding is that >> RFC 2616 explicitly allows that: >> >> Â Â "Multiple message-header fields with the same field-name MAY be >> present in a message if and only if the entire field-value for that >> header field is defined as a comma-separated list [i.e., #(values)]. It >> MUST be possible to combine the multiple header fields into one >> 'field-name: field-value' pair, without changing the semantics of the >> message, by appending each subsequent field-value to the first, each >> separated by a comma." > > You're correct, but that doesn't mean the implementations follow the > spec :-(. I can only speak for Set-Cookie, there you have to send each > cookie on a new line because the expires date format includes a comma > and Firefox and IE can't handle that. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 7, 2010

Re: [Pharo-project] XML Parser, Monticello and unicode?

by Norbert Hartl

On 07.08.2010, at 13:19, StÃ©phane Ducasse wrote: >>>> >>>> >> Has this been reported before? If not why? This is really important. I don't think we can wait until Monticello is replaced by something different that will fix this :) > > > the anwser is: > - check bug entries > - add new one if necessary > - propose a fix if possible > - else wait. > I replied to Henriks mail. It was meant as a question to him because he knows about the topic. I see I need to be more clear next time. And btw. this was _not_ an answer to my question. >> >> There are a few things here that work together in 98% of all cases. I didn't get it fully what is going on but >> >> ZipArchiveMember>>contentStream does >> ... >> s := MultiByteBinaryOrTextStream on: (String new: self uncompressedSize). >> s converter: Latin1TextConverter new. >> ... >> >> and >> >> MultiByteBinaryOrTextStream>>defaultConverter >> ^ Latin1TextConverter new. >> >> These two are being used when a monticello package is being read. So we have an assumption about an encoding here. On the other hand something in the system does something similar. I don't know InputEvents and how to debug them but if I create a method >> >> EncTest>>encTest >> ^ 'Ã¶' >> >> I can see that >> >> ((EncTest>>#encTest literalAt: 1) at: 1) asciiValue >> >> is 246 which is something that matches latin1 to some extent. >> >> This way there is a conversion (I think at the time I press on my keyboard) to latin1. While writing a monticello package I didn't find any conversion so this might be the reason that the files become latin1 on disk and can be read back using an explicit conversion from latin1. >> >> But this does not explain how it does work with WideString. I would need to dig deeper but maybe someone of you have an idea. >> >> To estimate the possibility to change this I think we should fix this. I scanned all of my cached monticello packages. Most of them are 7bit clean. > > how do you do that? for i in `find . -name "*.mcz"`; do echo $i; unzip -qc $i snapshot/source.st | enca -L none; done > >> No problem for them if we change encoding. Besides XML Parser I didn't find any that contain WideString so no problem here. Some of them are latin1 encoded (like Seaside 2.8 or Seaside-InternetExplorer from 3.0). That is the biggest problem because there is no fallback and monticello does not have a version number on file format, right? >> I think it is still feasible to change this in monticello as the fix for users of older images will be probably only a few lines that you can apply to any version of monticello if I'm not wrong. But the change is not that easy. > > > This is not clear to me what is the problem and potential solution. I was not concentrated enough on pharo :( It is not clear to me, either. That's why I am asking. I'm willing to track this down any further. At least i want to open a substantial ticket. But a little bit more information would be helpful. Norbert

Aug. 7, 2010