- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Alain Plantec

Le 23/09/2010 20:20, Juan Vuletich a Ã©crit : > > Hi Folks, > > I included in Cuis the fonts I think are most needed. If you want to > build other sizes, all you need is > http://www.jvuletich.org/Cuis/AAFonts.zip and the methods already in > StrikeFont. That zip file includes regular, bold, italic and bold > italic for all sizes between 5 and 24. > > Have fun with it! yes! I've load them in pharo. Thanks a lot Juan A package for Pharo will be available soon. Cheers Alain > > Cheers, > Juan Vuletich >

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Eliot, The presumption is still incorrect, because it charms that time interval rather than the conditions, whether that be other network traffic, or simply whether the user is thinking "geez, I know that machine was up five minutes ago" or "just cancel already so I can type the correct address this time." Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Thursday, September 23, 2010 2:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, Sep 23, 2010 at 10:01 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Levente, I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands. Sockets don't decide when to free resources. Threads and users do. Wilhelm, asking a socket to timeout after a while is /not/ a socket "deciding when to free resources". The socket doesn't decide for itself. The client of the socket, be that a server or a user or whatever, does. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one. My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory. And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around. Here is an example for a blocking connection without a timeout: Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork. > > ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs. ConnectionQueue is just a high level API, you can always use _Sockets_. Levente > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] > Sent: Wednesday, September 22, 2010 11:51 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. > > If the UI Process is using the Socket and it's using a blocking connection > method, then - no surprise - it will be blocked. This won't affect other > processes. > > If you were right, the following would block the UI Process for 100 > seconds, but it doesn't block it at all, just try it: > > Transcript open. > [ 10 timesRepeat: [ > | s | > [ > s := Socket new. > s connectNonBlockingTo: #[172 16 0 1] port: 12345. > s > waitForConnectionFor: 10 > ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. > s isConnected ifTrue: [ > Transcript show: 'Connected.'; cr. ]. > s close ] ensure: [ > s ifNotNil: [ s destroy ] ] ] ] fork. > > > What do you mean by "servers"? ConnectionQueue? > > > Levente > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] >> Sent: Wednesday, September 22, 2010 9:55 PM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> the one running the gui >> >> In that case, you're wrong. The UI Process will be able to run, because >> other processes using Sockets will wait on Semaphores and not because of >> "time limits". So I just convinced myself (and hopefully you too) about >> that using Socket instances will not hang the entire image, just the >> Process that uses the Socket. Therefore the SocketPlugin is as good as >> possible. >> >> >> Levente >> >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] >>> Sent: Monday, September 20, 2010 10:14 PM >>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. >>> >>> Where? In the Socket class? And what's the "main thread"? >>> >>> >>> Levente >>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] >>>> Sent: Monday, September 20, 2010 8:13 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Levente, >>>>> >>>>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >>>> >>>> I guess you're using Socket>>#connectTo:port: which uses >>>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>>> implement your own low level method which waits on semaphore until it's >>>> signaled. If you want to terminate the connection attempt, just signal the >>>> semaphore yourself, like here: >>>> >>>> s := Socket newTCP. >>>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >>>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >>>> s semaphore waitTimeoutMSecs: 1000. >>>> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >>>> >>>> And for ConnectionQueue, simply don't use it if you don't like it. It >>>> doesn't have to poll at all, AFAIK it's just implemented that way. >>>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>>> don't block the image at all. But correct me if I'm wrong. >>>> >>>> >>>> Levente >>>> >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Levente Uzonyi [leves(a)elte.hu<mailto:leves@elte.hu>] >>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>>> >>>>>> Guillermo, >>>>>> >>>>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>>>> >>>>> When does a Socket block the image? >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com<mailto:guillermopolito@gmail.com>] >>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>> >>>>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>>>> >>>>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>>>> >>>>>> Guille >>>>>> >>>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>>> wrote: >>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote: >>>>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>>>> >>>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>>> where you can add any properties to object >>>>>> on the fly, without need of adding a methods or declaring additional >>>>>> instance variable in class... >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>>] >>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> >>>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>>> >>>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr><mailto:stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>>> wrote: >>>>>>>> hi guys >>>>>>>> >>>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>>>> So we should really have a way to specify silent ui action. >>>>>>>> Does anybody have an idea how I could do that? >>>>>>>> >>>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>>>> >>>>>>> >>>>>>> use morph propertyAt: #borderStyle >>>>>>> so you don't have to break your head with it :) >>>>>>> >>>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>>> them even don't using any >>>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>>> style etc should belong to root classes >>>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>>> properties (which is currently sits in morphic >>>>>>> extensions are more appropriate storage for them). The only problem is >>>>>>> that accessing them is much slower than ivars. >>>>>>> >>>>>>>> Stef >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 23, 2010

Re: [Pharo-project] TextLint questions and feedback

by Mariano Martinez Peck

On Thu, Sep 23, 2010 at 8:07 PM, Jorge Ressia <jorge.ressia(a)gmail.com>wrote: > Hi Mariano, > > We are very happy that you found TextLint that useful. As you might > have noticed we fixed several of your reported issues and we are still > working on the remaining ones. > yes, thanks a lot :) > > 1.- Not difficult. Could you specify how this rule would work? how > many sentences should we take into account? Perhaps a whole paragraph. > You might find the rule TLWordRepetitionInParagraphRule, which is > already in TextLint useful, it detects the repetition of words in a > paragraphs. If the Word is used more than 3 times then the rule fails. > This will include the connectors that you mentioned. If you required a > repetition rule a little more strict you can always use this rule as a > basis for defining your new rule. We will be more that happy to > integrate it :) > Maybe the rule can be very similar to the one you say. My scenario is the following: several times I need connectors or things like: "However, In contrast to, In adddition, Furthermore, On the other hand, Still, Furthermore, Nevertheless, etc....". And then I need one of them, I usually have to check near that place where I need it, if I have already use one of them. I check in the same paragraph or just near. So a rule can be something like TLWordRepetitionInParagraphRule but: - I wouldn't like to repeated even twice (not 3!!). I just want them only once in the near text - I wouldn't do it for ALL words, only for those kind of words - I would check in the same paragraph or maybe 10 (15, or 20) lines before and after the place. > > 2.- The objective behind "Do not join sentences with commas " is > simplicity. If you have a sentence with a single comma you might be > expressing two different things and divide them in two sentences might > be good. On the other hand, if you still want to keep your sentence > together this rule might signal that it might be a way of avoiding the > use of the coma and using some meaningful connector. > In any case, I agree that this rule is spotted several times in the > most text and TextLint users might feel reluctant to look into it. > We have planned to look into it. > But in many cases it has been quite useful for me. > > Thanks for the explanantion Jorge. Mariano > Cheers, > > On Thu, Sep 23, 2010 at 4:14 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Ok....I am using TextLint for all my papers now :) > > > > Few more things: > > > > 1) It would be awesome a rule that detects duplication of connectors in a > > near area. For example, if I use connectors like "However, Nevertheless, > > Hence, On the contrary, One the other hand, etc..." it would be nice a > rule > > that detects that you already use the same connector some lines > before/after > > a specific one... > > > > 2) I don't understand the rule: "Do not join sentences with commas ". Is > > this working well ? I have these phrases for example: > > > > > > - To support automatic memory management, most object oriented systems > are > > based on garbage collectors (GC) \cite{Jone96a}. > > > > - In class-based object-oriented languages, information about class usage > is > > needed. > > > > - For this we use Distribution Map, a visualization showing spread and > focus > > of properties across systems. > > > > I think the "comma" there are correct. Maybe I am wrong. > > > > Thanks > > > > mariano > > > > > > On Thu, Sep 2, 2010 at 9:34 PM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> On Thu, Sep 2, 2010 at 9:20 PM, Jorge Ressia <jorge.ressia(a)gmail.com> > >> wrote: > >>> > >>> Hi, > >>> > >>> So > >> > >> I have just sent you by private email the .tex. > >> > >>> > >>> 1) Could not reproduce > >>> > >> > >> Should be reproducable with my .tex > >> > >>> > >>> 2) > >>> 2.a) Working on that > >>> 2.b) Could not reproduce > >>> > >> > >> me neither. Did you check if you are using a Set for the collection? > >> > >>> > >>> 3) It is hard to achieve, we still have it in the todo list. > >> > >> Yes, I imagined ;) > >> > >>> > >>> 4) Could not reproduce > >>> > >> > >> Should be reproducable with my .tex > >> > >>> > >>> 5) Fixed > >>> > >>> 6) Checking > >>> > >> > >> excellent :) > >> > >>> > >>> It would be cool if we could have a look at your file so we can have a > >>> better way of debugging these issues. > >>> > >> > >> Done :) > >> > >>> > >>> Thanks > >>> > >>> > >>> > >>> On Thu, Sep 2, 2010 at 6:54 PM, Jorge Ressia <jorge.ressia(a)gmail.com> > >>> wrote: > >>> > Hi Mariano, > >>> > > >>> > Thanks for trying TextLint out and for the feedback. > >>> > > >>> > We will look into your issues and try to figure out a solution. > >>> > > >>> > If you have a draft of your text with these occurrences please send > it > >>> > to us. You can remove the text that is not relevant. > >>> > > >>> > Cheers, > >>> > > >>> > Jorge > >>> > > >>> > 2010/9/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >>> >> Hi. First, please let me know if this is the correct place to talk > >>> >> about > >>> >> TextLint. I've just used for one paper I am writing and I have some > >>> >> questions/feedback. I am using the one click image. > >>> >> > >>> >> 1) The "An Rule" could be a little more smart and detects commands. > >>> >> For > >>> >> example, in my latex I have " an \emph{inner object}" and that was > >>> >> detected > >>> >> by the rule, althought I shouldn't. So...detecting the slash and > >>> >> ignore what > >>> >> it surrounded by {} would be nice for this rule. > >>> >> > >>> >> 2) When I edit the code inside TextLint and I save it, two bad > things > >>> >> happens: > >>> >> 2.a) I lost focus of the text, as it moves when it finishing > >>> >> saving. > >>> >> The line I edited goes to the end of the text area. It would be > great > >>> >> if > >>> >> nothing moves nor to loose focus when saving. > >>> >> 2.b) sometimes (I cannot reproduce) the order of the rules > >>> >> changes...and this is not good because I was going in order, one by > >>> >> one, and > >>> >> suddenly they are re-ordered. Maybe you are using a Set for that? > >>> >> using a > >>> >> simple OrderedCollection could help. > >>> >> > >>> >> 3) If you edit the text (and it differs in the amount of > characters), > >>> >> and DO > >>> >> NOT save it, the following color highlighting are moved. It seems > you > >>> >> keep > >>> >> the position in the file, and until it is saved, rules results are > >>> >> pointing > >>> >> to "unupdated" file. Of course, when I save the file, they are > >>> >> correct. I > >>> >> guess this is from a performance point of view, but maybe you have a > >>> >> little > >>> >> hack to do and make it better. > >>> >> > >>> >> 4) The rule "no white space before punctuation mark" showed me > things > >>> >> I > >>> >> didn't understand. For example, it says this line there is a "," > >>> >> (comma) : > >>> >> > >>> >> \item[ Shared object ] In the case of the \emph{shared objects}, > it > >>> >> is > >>> >> almost the same as in the \emph{inner objects}. An ..... > >>> > > >>> > > >>> >> 5) Rules comments clearer. For example, when you say "Avoid using a > >>> >> lot, it > >>> >> weakens the sentence" It would be better to put "Avoid using "a > lot", > >>> >> it > >>> >> weakens the sentence" > >>> >> or "Avoid using *a lot*, it weakens the sentence" > >>> >> or something to clearly mark the words not to use. Because sometimes > >>> >> the > >>> >> words are confused with the context. Or this one: > >>> >> > >>> >> "After an only words beginning with a vowel are allowed. " > >>> >> should be "After "an" only words beginning with a vowel are > allowed." > >>> >> > >>> >> 6) For the rules of long sentences/paragraph it would be nice to > >>> >> ignore > >>> >> \fotenote{} > >>> >> > >>> >> 7) Maybe this link is of interest for you: > >>> >> > >>> >> > http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words… > >>> >> > >>> >> Apart from all these things, the tool is very useful and I like it. > >>> >> > >>> >> thanks > >>> >> > >>> >> Mariano > >>> >> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> Pharo-project mailing list > >>> >> Pharo-project(a)lists.gforge.inria.fr > >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > Jorge Ressia > >>> > www.jorgeressia.com > >>> > > >>> > >>> > >>> > >>> -- > >>> Jorge Ressia > >>> www.jorgeressia.com > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > Jorge Ressia > www.jorgeressia.com >

Sept. 23, 2010

Re: [Pharo-project] A pattern for GUI programming (Morphic, Cuis, etc)

by Juan Vuletich

Noury Bouraqadi wrote: > Hi Juan, > > Is this document available somewhere on the web? It's important to ensure it is persistence. > > Noury > Hi Noury, It is now at http://www.jvuletich.org/Cuis/APatternForGUIProgramming.html . Cheers, Juan Vuletich

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Eliot Miranda

On Thu, Sep 23, 2010 at 10:01 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Levente, > > I never said that. I said that if it were built properly and used naively, > it would have led to problems. Enter timeouts that should not be present. > The server side is almost impossible to defend as it stands. > > Sockets don't decide when to free resources. Threads and users do. > Wilhelm, asking a socket to timeout after a while is /not/ a socket "deciding when to free resources". The socket doesn't decide for itself. The client of the socket, be that a server or a user or whatever, does. > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > Sent: Thursday, September 23, 2010 12:25 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > > On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote: > > > Levente, > > > > We can twist words indefinitely. I have been describing a blocking > connect, because that is precisely what one should be trying to do: put one > thread on hold until the calling thread is connected. There is no sensible > default waiting period for that to happen, and so the framework should not > be asking for a time limit at all, let alone insisting on one. > > My example was just a proof against the "we need a new socket > implementation because the current one blocks the image" theory. > > And you're wrong about the timeouts. If sockets could wait indefinitely, > the chance for resource leakage would be very high. I'm pretty sure that > even if you omit the timeout (which is possible with the current API) > there will be another timeout at the OS level which you can't/shouldn't > work around. > > Here is an example for a blocking connection without a timeout: > > Transcript open. > [ > | s | > [ > s := Socket new. > s connectNonBlockingTo: #[172 16 0 1] port: 12345. > Transcript show: 'Connecting...'; cr. > [ s statusString = 'waitingForConnection' ] whileTrue: [ > s semaphore wait. "No timeout." ]. > Transcript show: s statusString; cr. > s close ] ensure: [ s destroy ] ] fork. > > > > > ConnectionQueue being at the heart of a Squeak socket server is not my > idea; I read that in various places, tried, and was appalled to discover > that it times out, returns nil, etc. It is a complete mess that polls for a > time period when it should be blocking a thread until an event occurs. > > ConnectionQueue is just a high level API, you can always use _Sockets_. > > > Levente > > > > > Bill > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > > Sent: Wednesday, September 22, 2010 11:51 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > > > > On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > > > >> Levente, > >> > >> Something has to block while a connection attempt is pending, and not > just until some arbitrary time limit. The client code is bad enough; the > servers are horrible. > > > > If the UI Process is using the Socket and it's using a blocking > connection > > method, then - no surprise - it will be blocked. This won't affect other > > processes. > > > > If you were right, the following would block the UI Process for 100 > > seconds, but it doesn't block it at all, just try it: > > > > Transcript open. > > [ 10 timesRepeat: [ > > | s | > > [ > > s := Socket new. > > s connectNonBlockingTo: #[172 16 0 1] port: 12345. > > s > > waitForConnectionFor: 10 > > ifTimedOut: [ Transcript show: 'Couldn''t > connect.'; cr ]. > > s isConnected ifTrue: [ > > Transcript show: 'Connected.'; cr. ]. > > s close ] ensure: [ > > s ifNotNil: [ s destroy ] ] ] ] fork. > > > > > > What do you mean by "servers"? ConnectionQueue? > > > > > > Levente > > > >> > >> Bill > >> > >> > >> ________________________________________ > >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > >> Sent: Wednesday, September 22, 2010 9:55 PM > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > >> > >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> > >>> the one running the gui > >> > >> In that case, you're wrong. The UI Process will be able to run, because > >> other processes using Sockets will wait on Semaphores and not because of > >> "time limits". So I just convinced myself (and hopefully you too) about > >> that using Socket instances will not hang the entire image, just the > >> Process that uses the Socket. Therefore the SocketPlugin is as good as > >> possible. > >> > >> > >> Levente > >> > >>> > >>> > >>> > >>> > >>> ________________________________________ > >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > >>> Sent: Monday, September 20, 2010 10:14 PM > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > >>> > >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >>> > >>>> Scratch around, and you will find that the time limits are there to > allow calls to made on the main thread. > >>> > >>> Where? In the Socket class? And what's the "main thread"? > >>> > >>> > >>> Levente > >>> > >>>> > >>>> > >>>> > >>>> ________________________________________ > >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > >>>> Sent: Monday, September 20, 2010 8:13 PM > >>>> To: Pharo-project(a)lists.gforge.inria.fr > >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > >>>> > >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >>>> > >>>>> Levente, > >>>>> > >>>>> If they worked correctly, they would, at least under naive client > conditions - a connection attempt should try until it is told (#terminate) > to stop. Severs that listen for a limited time are broken by design. > ConnectionQueue polls as a result - it's pretty bad. > >>>> > >>>> I guess you're using Socket>>#connectTo:port: which uses > >>>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't > want > >>>> the default timeout, use #connectTo:port:waitForConnectionFor: or > >>>> implement your own low level method which waits on semaphore until > it's > >>>> signaled. If you want to terminate the connection attempt, just signal > the > >>>> semaphore yourself, like here: > >>>> > >>>> s := Socket newTCP. > >>>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which > is not open." > >>>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This > process will stop the connection attempt." > >>>> s semaphore waitTimeoutMSecs: 1000. > >>>> s statusString. "This will simply print the socket status. You can > terminate the process here if the socket is connected, etc." > >>>> > >>>> And for ConnectionQueue, simply don't use it if you don't like it. It > >>>> doesn't have to poll at all, AFAIK it's just implemented that way. > >>>> Since Sockets use Semaphores which are signaled by the SocketPlugin, > they > >>>> don't block the image at all. But correct me if I'm wrong. > >>>> > >>>> > >>>> Levente > >>>> > >>>>> > >>>>> Bill > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [ > leves(a)elte.hu] > >>>>> Sent: Monday, September 20, 2010 7:01 PM > >>>>> To: Pharo-project(a)lists.gforge.inria.fr > >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > >>>>> > >>>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >>>>> > >>>>>> Guillermo, > >>>>>> > >>>>>> One has to be careful with assuming that something affects only part > of the image. Much of Squeak's networking trouble comes from the fact that > it was designed to block the image for a limited time when it should have > been blocking only one Process *indefinitely*. But, the remedy for working > while blocking operations happen in the background is threading, and most of > the image is deliberately not thread safe. > >>>>> > >>>>> When does a Socket block the image? > >>>>> > >>>>> > >>>>> Levente > >>>>> > >>>>>> > >>>>>> Bill > >>>>>> > >>>>>> > >>>>>> ________________________________________ > >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito > [guillermopolito(a)gmail.com] > >>>>>> Sent: Sunday, September 19, 2010 10:56 PM > >>>>>> To: Pharo-project(a)lists.gforge.inria.fr > >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that > an action is UIless > >>>>>> > >>>>>> +1 to Bill's. If we can't have a feedback from the system while > doing silent actions, we can think it just freezed :S. > >>>>>> > >>>>>> And it's something already dicussed, but I don't like actions that > affect only a part of the system blocking my whole image. > >>>>>> > >>>>>> Guille > >>>>>> > >>>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > >>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>> wrote: > >>>>>>> Slow access can be a big problem. Any such change should be made > based on measurements so we know what benefit we get at what cost. > >>>>>>> > >>>>>> Yeah, it would be much easier to deal that line in Self or > JavaScript, > >>>>>> where you can add any properties to object > >>>>>> on the fly, without need of adding a methods or declaring additional > >>>>>> instance variable in class... > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto: > pharo-project-bounces(a)lists.gforge.inria.fr> [ > pharo-project-bounces(a)lists.gforge.inria.fr<mailto: > pharo-project-bounces(a)lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [ > siguctua(a)gmail.com<mailto:siguctua@gmail.com>] > >>>>>>> Sent: Sunday, September 19, 2010 7:56 PM > >>>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto: > Pharo-project(a)lists.gforge.inria.fr> > >>>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that > an action is UIless > >>>>>>> > >>>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > >>>>>>>> hi guys > >>>>>>>> > >>>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar > showing the progress blow up. > >>>>>>>> So we should really have a way to specify silent ui action. > >>>>>>>> Does anybody have an idea how I could do that? > >>>>>>>> > >>>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would > be cool. > >>>>>>>> > >>>>>>> > >>>>>>> use morph propertyAt: #borderStyle > >>>>>>> so you don't have to break your head with it :) > >>>>>>> > >>>>>>> BorderedMorph having an enormous number of subclasses, while some > of > >>>>>>> them even don't using any > >>>>>>> kind of borders. That's makes me wonder if anything like color, > border > >>>>>>> style etc should belong to root classes > >>>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set > of > >>>>>>> properties (which is currently sits in morphic > >>>>>>> extensions are more appropriate storage for them). The only problem > is > >>>>>>> that accessing them is much slower than ivars. > >>>>>>> > >>>>>>>> Stef > >>>>>>>> _______________________________________________ > >>>>>>>> Pharo-project mailing list > >>>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto: > 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<mailto: > 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<mailto: > 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<mailto: > 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 > >>> > >> > >> _______________________________________________ > >> 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 >

Sept. 23, 2010

Re: [Pharo-project] DejaVu extra sizes Re: DemoMode should not change Fonts only sizes?

by Juan Vuletich

Alain Plantec wrote: > Le 23/09/2010 16:03, Henrik Johansen a Ã©crit : >> Sounds like a plan, I feel the StrikeFont port from Cuis is new >> robust enough now to drop accuny completely. >> Personally I find 7 a good size for tooltips/buttons, haven't used >> the even smaller sizes. >> > too small here, but of course, the 7 is available if we want to > include it. >> The package should be updated to provide proper derived fonts for >> Bold Italic though. > notice that the 22 has Undelined and Italic-Underlined too >> >> Also, is there a specific reason bitmaps for Italic underlined is >> included for size 12, and no others? >> > I don't know why but it seems that it is like that in Cuis. > Maybe Juan could tell us ? > > I've only implemented some methods in order to automatically extract > them from Cuis. > Alain > >> Cheers, >> Henry >> Hi Folks, I included in Cuis the fonts I think are most needed. If you want to build other sizes, all you need is http://www.jvuletich.org/Cuis/AAFonts.zip and the methods already in StrikeFont. That zip file includes regular, bold, italic and bold italic for all sizes between 5 and 24. Have fun with it! Cheers, Juan Vuletich

Sept. 23, 2010

Re: [Pharo-project] TextLint questions and feedback

by Jorge Ressia

Hi Mariano, We are very happy that you found TextLint that useful. As you might have noticed we fixed several of your reported issues and we are still working on the remaining ones. 1.- Not difficult. Could you specify how this rule would work? how many sentences should we take into account? Perhaps a whole paragraph. You might find the rule TLWordRepetitionInParagraphRule, which is already in TextLint useful, it detects the repetition of words in a paragraphs. If the Word is used more than 3 times then the rule fails. This will include the connectors that you mentioned. If you required a repetition rule a little more strict you can always use this rule as a basis for defining your new rule. We will be more that happy to integrate it :) 2.- The objective behind "Do not join sentences with commas " is simplicity. If you have a sentence with a single comma you might be expressing two different things and divide them in two sentences might be good. On the other hand, if you still want to keep your sentence together this rule might signal that it might be a way of avoiding the use of the coma and using some meaningful connector. In any case, I agree that this rule is spotted several times in the most text and TextLint users might feel reluctant to look into it. We have planned to look into it. But in many cases it has been quite useful for me. Cheers, On Thu, Sep 23, 2010 at 4:14 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Ok....I am using TextLint for all my papers now :) > > Few more things: > > 1) It would be awesome a rule that detects duplication of connectors in a > near area. For example, if I use connectors like "However, Nevertheless, > Hence, On the contrary, One the other hand, etc..."Â it would be nice a rule > that detects that you already use the same connector some lines before/after > a specific one... > > 2) I don't understand the rule: "Do not join sentences with commas ".Â Is > this working well ?Â Â I have these phrases for example: > > > - To support automatic memory management, most object oriented systems are > based on garbage collectors (GC) \cite{Jone96a}. > > - In class-based object-oriented languages, information about class usage is > needed. > > - For this we use Distribution Map, a visualization showing spread and focus > of properties across systems. > > I think the "comma" there are correct. Maybe I am wrong. > > Thanks > > mariano > > > On Thu, Sep 2, 2010 at 9:34 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> On Thu, Sep 2, 2010 at 9:20 PM, Jorge Ressia <jorge.ressia(a)gmail.com> >> wrote: >>> >>> Hi, >>> >>> So >> >> I have just sent you by private email the .tex. >> >>> >>> 1) Could not reproduce >>> >> >> Should be reproducable with my .tex >> >>> >>> 2) >>> Â Â 2.a) Working on that >>> Â Â 2.b) Could not reproduce >>> >> >> me neither. Did you check if you are using a Set for the collection? >> >>> >>> 3) It is hard to achieve, we still have it in the todo list. >> >> Yes, I imagined ;) >> >>> >>> 4) Could not reproduce >>> >> >> Should be reproducable with my .tex >> >>> >>> 5) Fixed >>> >>> 6) Checking >>> >> >> excellent :) >> >>> >>> It would be cool if we could have a look at your file so we can have a >>> better way of debugging these issues. >>> >> >> Done :) >> >>> >>> Thanks >>> >>> >>> >>> On Thu, Sep 2, 2010 at 6:54 PM, Jorge Ressia <jorge.ressia(a)gmail.com> >>> wrote: >>> > Hi Mariano, >>> > >>> > Thanks for trying TextLint out and for the feedback. >>> > >>> > We will look into your issues and try to figure out a solution. >>> > >>> > If you have a draft of your text with these occurrences please send it >>> > to us. You can remove the text that is not relevant. >>> > >>> > Cheers, >>> > >>> > Jorge >>> > >>> > 2010/9/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >> Hi. First, please let me know if this is the correct place to talk >>> >> about >>> >> TextLint. I've just used for one paper I am writing and I have some >>> >> questions/feedback. I am using the one click image. >>> >> >>> >> 1) The "An Rule" could be a little more smart and detects commands. >>> >> For >>> >> example, in my latex I have " an \emph{inner object}"Â and that was >>> >> detected >>> >> by the rule, althought I shouldn't. So...detecting the slash and >>> >> ignore what >>> >> it surrounded by {} would be nice for this rule. >>> >> >>> >> 2) When I edit the code inside TextLint and I save it, two bad things >>> >> happens: >>> >> Â Â Â Â 2.a)Â I lost focus of the text, as it moves when it finishing >>> >> saving. >>> >> The line I edited goes to the end of the text area. It would be great >>> >> if >>> >> nothing moves nor to loose focus when saving. >>> >> Â Â Â Â 2.b) sometimes (I cannot reproduce) the order of the rules >>> >> changes...and this is not good because I was going in order, one by >>> >> one, and >>> >> suddenly they are re-ordered. Maybe you are using a Set for that? >>> >> using a >>> >> simple OrderedCollection could help. >>> >> >>> >> 3) If you edit the text (and it differs in the amount of characters), >>> >> and DO >>> >> NOT save it, the following color highlighting are moved. It seems you >>> >> keep >>> >> the position in the file, and until it is saved, rules results are >>> >> pointing >>> >> to "unupdated" file. Of course, when I save the file, they are >>> >> correct. I >>> >> guess this is from a performance point of view, but maybe you have a >>> >> little >>> >> hack to do and make it better. >>> >> >>> >> 4) The rule "no white space before punctuation mark" showed me things >>> >> I >>> >> didn't understand. For example, it says this line there is a "," >>> >> (comma) : >>> >> >>> >> \item[ Shared object ]Â Â In the case of the \emph{shared objects}, it >>> >> is >>> >> almost the same as in the \emph{inner objects}. An ..... >>> > >>> > >>> >> 5) Rules comments clearer. For example, when you say "Avoid using a >>> >> lot, it >>> >> weakens the sentence"Â It would be better to put "Avoid using "a lot", >>> >> it >>> >> weakens the sentence" >>> >> or "Avoid using *a lot*, it weakens the sentence" >>> >> or something to clearly mark the words not to use. Because sometimes >>> >> the >>> >> words are confused with the context. Or this one: >>> >> >>> >> "After an only words beginning with a vowel are allowed. " >>> >> should be "After "an" only words beginning with a vowel are allowed." >>> >> >>> >> 6) For the rules of long sentences/paragraph it would be nice to >>> >> ignore >>> >> \fotenote{} >>> >> >>> >> 7) Maybe this link is of interest for you: >>> >> >>> >> http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words… >>> >> >>> >> Apart from all these things, the tool is very useful and I like it. >>> >> >>> >> thanks >>> >> >>> >> Mariano >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Pharo-project mailing list >>> >> Pharo-project(a)lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >>> > >>> > >>> > >>> > -- >>> > Jorge Ressia >>> > www.jorgeressia.com >>> > >>> >>> >>> >>> -- >>> Jorge Ressia >>> www.jorgeressia.com >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- Jorge Ressia www.jorgeressia.com

Sept. 23, 2010

Re: [Pharo-project] Copy from Code::Blocks on Linux

by Chris Muller

Try "export LC_ALL=C" before starting your images, or maybe "export LC_ALL=en_US.UTF-8". On Wed, Sep 22, 2010 at 12:57 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hello all, > > A frequent problem I encounter: select and copy text from an editor in Code::Blocks; on pasting into Pharo, I get something other than what I copied. Â Any ideas what might be happening? Â Are there multiple clipboards on Linux? Â Could it be a mismatch in format? Â I'm using Ubuntu. > > I frequently work around this by pasting the code into gedit and then copying again from there, after which Pharo "sees" it. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Levente, I never said that. I said that if it were built properly and used naively, it would have led to problems. Enter timeouts that should not be present. The server side is almost impossible to defend as it stands. Sockets don't decide when to free resources. Threads and users do. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Thursday, September 23, 2010 12:25 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > We can twist words indefinitely. I have been describing a blocking connect, because that is precisely what one should be trying to do: put one thread on hold until the calling thread is connected. There is no sensible default waiting period for that to happen, and so the framework should not be asking for a time limit at all, let alone insisting on one. My example was just a proof against the "we need a new socket implementation because the current one blocks the image" theory. And you're wrong about the timeouts. If sockets could wait indefinitely, the chance for resource leakage would be very high. I'm pretty sure that even if you omit the timeout (which is possible with the current API) there will be another timeout at the OS level which you can't/shouldn't work around. Here is an example for a blocking connection without a timeout: Transcript open. [ | s | [ s := Socket new. s connectNonBlockingTo: #[172 16 0 1] port: 12345. Transcript show: 'Connecting...'; cr. [ s statusString = 'waitingForConnection' ] whileTrue: [ s semaphore wait. "No timeout." ]. Transcript show: s statusString; cr. s close ] ensure: [ s destroy ] ] fork. > > ConnectionQueue being at the heart of a Squeak socket server is not my idea; I read that in various places, tried, and was appalled to discover that it times out, returns nil, etc. It is a complete mess that polls for a time period when it should be blocking a thread until an event occurs. ConnectionQueue is just a high level API, you can always use _Sockets_. Levente > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Wednesday, September 22, 2010 11:51 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> Something has to block while a connection attempt is pending, and not just until some arbitrary time limit. The client code is bad enough; the servers are horrible. > > If the UI Process is using the Socket and it's using a blocking connection > method, then - no surprise - it will be blocked. This won't affect other > processes. > > If you were right, the following would block the UI Process for 100 > seconds, but it doesn't block it at all, just try it: > > Transcript open. > [ 10 timesRepeat: [ > | s | > [ > s := Socket new. > s connectNonBlockingTo: #[172 16 0 1] port: 12345. > s > waitForConnectionFor: 10 > ifTimedOut: [ Transcript show: 'Couldn''t connect.'; cr ]. > s isConnected ifTrue: [ > Transcript show: 'Connected.'; cr. ]. > s close ] ensure: [ > s ifNotNil: [ s destroy ] ] ] ] fork. > > > What do you mean by "servers"? ConnectionQueue? > > > Levente > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >> Sent: Wednesday, September 22, 2010 9:55 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> the one running the gui >> >> In that case, you're wrong. The UI Process will be able to run, because >> other processes using Sockets will wait on Semaphores and not because of >> "time limits". So I just convinced myself (and hopefully you too) about >> that using Socket instances will not hang the entire image, just the >> Process that uses the Socket. Therefore the SocketPlugin is as good as >> possible. >> >> >> Levente >> >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>> Sent: Monday, September 20, 2010 10:14 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. >>> >>> Where? In the Socket class? And what's the "main thread"? >>> >>> >>> Levente >>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>> Sent: Monday, September 20, 2010 8:13 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Levente, >>>>> >>>>> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. >>>> >>>> I guess you're using Socket>>#connectTo:port: which uses >>>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>>> implement your own low level method which waits on semaphore until it's >>>> signaled. If you want to terminate the connection attempt, just signal the >>>> semaphore yourself, like here: >>>> >>>> s := Socket newTCP. >>>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." >>>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." >>>> s semaphore waitTimeoutMSecs: 1000. >>>> s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." >>>> >>>> And for ConnectionQueue, simply don't use it if you don't like it. It >>>> doesn't have to poll at all, AFAIK it's just implemented that way. >>>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>>> don't block the image at all. But correct me if I'm wrong. >>>> >>>> >>>> Levente >>>> >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] >>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>> >>>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>>> >>>>>> Guillermo, >>>>>> >>>>>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >>>>> >>>>> When does a Socket block the image? >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>> >>>>>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>>>>> >>>>>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>>>>> >>>>>> Guille >>>>>> >>>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>>>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>>>>> >>>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>>> where you can add any properties to object >>>>>> on the fly, without need of adding a methods or declaring additional >>>>>> instance variable in class... >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>>>>> >>>>>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>>>>> hi guys >>>>>>>> >>>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>>>>> So we should really have a way to specify silent ui action. >>>>>>>> Does anybody have an idea how I could do that? >>>>>>>> >>>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>>>>> >>>>>>> >>>>>>> use morph propertyAt: #borderStyle >>>>>>> so you don't have to break your head with it :) >>>>>>> >>>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>>> them even don't using any >>>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>>> style etc should belong to root classes >>>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>>> properties (which is currently sits in morphic >>>>>>> extensions are more appropriate storage for them). The only problem is >>>>>>> that accessing them is much slower than ivars. >>>>>>> >>>>>>>> Stef >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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<mailto:Pharo-project@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 >>> >> >> _______________________________________________ >> 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 >

Sept. 23, 2010

Re: [Pharo-project] decompiledSource

by Eliot Miranda

On Thu, Sep 23, 2010 at 5:14 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On Sep 23, 2010, at 1:35 18PM, Herve Verjus wrote: > > > Hello All, > > > > I would like to port some VisualWorks code into Pharo. The VW current > project code uses VW Kernel.decompiledSource that does not seem to be > implemented in Pharo...Is there a Pharo method that does the same...Is there > someone with an idea ? > > > > Thank you... > > > > Herve > If you mean CompiledBlock/CompiledCode #decompiledSource, I think the > equivalent in Pharo would be BlockClosure / CompiledMethod #decompile > Actually #decompileString. #decompile answers a parse tree. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 23, 2010