[Pharo-users] SquareBracket Associate github org ownership

[Serge Stinckwich]

Dear all,

who is in charge of SquareBracket Associate github org ? I can't
commit anymore on :
https://github.com/SquareBracketAssociates/NumericalMethods

Maybe I was owner before and no more now.
Can someone can change my ownership ?
Thank you.
Regards,

-- 
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-users] Noncontiguous selections in FastTable?

[Hernán Morales Durand]

Thanks Denis, it worked although I had to Alt+right-button which is weird
in Windows which commonly uses Ctrl+left button

Just a note for Pharo 5 users this method raises MNU

FTTableMorph class>>defaultBackgroundColor
^ Smalltalk ui theme listBackgroundColor

and could be replaced with the previous version:

FTTableMorph class>>defaultBackgroundColor
^ Smalltalk ui theme backgroundColor



2017-05-21 10:57 GMT-03:00 Denis Kudriashov :

> I fixed it in Pharo 6. Look at issue 19277
> 
> .
> Maybe you can just load updated packages for FastTable to fix your problem.
>
> 2017-05-20 22:41 GMT+02:00 Hernán Morales Durand  >:
>
>>
>> Any way to get noncontiguous selection working in FTTableMorph in Pharo 5?
>>
>> In Windows I cannot get two non-consecutive items to be selected.
>> Ctrl key causes menu to appear.
>> Shift key only allows consecutive items.
>>
>> See for example this FastTable:
>>
>> | ds |
>>
>> ds := FTTreeDataSource
>> roots: (1 to: 1000)
>> children: [ :data :item |
>> item depth even
>> ifTrue: [ 1 to: data / 2 ]
>> ifFalse: [ 1 to: data - 1 ] ].
>> FTTableMorph new
>> extent: 200 @ 400;
>> dataSource: ds;
>> allowDeselection;
>> beMultipleSelection;
>> secondarySelectionColor: Color tan;
>> openInWindow.
>>
>> Any help will be appreciated.
>> Cheers,
>>
>> Hernán
>>
>>
>

Re: [Pharo-users] Noncontiguous selections in FastTable?

[Denis Kudriashov]

I fixed it in Pharo 6. Look at issue 19277

.
Maybe you can just load updated packages for FastTable to fix your problem.

2017-05-20 22:41 GMT+02:00 Hernán Morales Durand :

>
> Any way to get noncontiguous selection working in FTTableMorph in Pharo 5?
>
> In Windows I cannot get two non-consecutive items to be selected.
> Ctrl key causes menu to appear.
> Shift key only allows consecutive items.
>
> See for example this FastTable:
>
> | ds |
>
> ds := FTTreeDataSource
> roots: (1 to: 1000)
> children: [ :data :item |
> item depth even
> ifTrue: [ 1 to: data / 2 ]
> ifFalse: [ 1 to: data - 1 ] ].
> FTTableMorph new
> extent: 200 @ 400;
> dataSource: ds;
> allowDeselection;
> beMultipleSelection;
> secondarySelectionColor: Color tan;
> openInWindow.
>
> Any help will be appreciated.
> Cheers,
>
> Hernán
>
>

Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)

[monty]

Creating two separate DOM subtrees for two descendants of the body element 
should be faster and consume less memory than creating one subtree for the 
entire body. You should also consider benchmarking different approaches, and 
using profiling to identify which of the parsing, querying, network IO, or 
whatever is your bottleneck before optimizing.

> Sent: Saturday, May 20, 2017 at 7:08 AM
> From: PBKResearch 
> To: "'Any question about pharo is welcome'" 
> Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] 
> ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)
>
> Monty
> 
> Many thanks for your patient explanation. I would like to try one 
> supplementary question, if I may. Almost all my work involves reading HTML 
> files from the web and extracting relevant sections, and I am trying to work 
> out how to divide the effort between StAX and XPath. For example, if I am 
> reading an article from Frankfurter Allgemeine, I am looking for two tags:
>  
> 
> which contain the intro and body of the article; everything else can be 
> discarded.
> 
> Using StAX, I can find the first  with something like this (adapted from 
> your second snippet):
> 
> [((tag := parser peek) isStartTagNamed: 'div') and: [ tag hasAttributes and: 
> [(tag attributeAt: 'class') = 'FAZArtikelEinleitung']]]
> whileFalse: [parser next].
> intro := parser nextNode.
> 
> and similarly for the body. I suppose if this is common I could subclass and 
> make this a method.
> 
> Does this look sensible, and is it more efficient than reading the entire 
> body with StAX and locating the relevant sections with XPath? (I have tried 
> this snippet, and it works. My question is really whether this is the best 
> way to go about it?)
> 
> Many thanks for any advice.
> 
> Peter Kenny
> 
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> monty
> Sent: 17 May 2017 22:10
> To: pharo-users@lists.pharo.org
> Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] 
> ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)
> 
> For example, this:
> ((StAXHTMLParser onURL: aURLString)
>   nextElementNamed: 'head')
>   ifNotNil: [:headElement | ...]
> 
> parses the document upto the next "head" element and returns it and any 
> descendants as a DOM subtree. If there's no next "head" element, it exhausts 
> the event stream looking for one. If you don't want that, test it first:
> (parser peek isStartTagNamed: 'head')
>   ifTrue: [| headElement |
>   headElement := parser nextNode.
>   ...].
> 
> because you now know what kind of DOM subtree the next events represent, 
> #nextNode is used, which builds any DOM subtree out of the next events, 
> including an element with descendants, a string or comment node, or even an 
> entire document (if sent before reading the start-of-document event). So this:
> (StAXHTMLParser onURL: aURLString) nextNode
> 
> is equivalent to this:
> XMLHTMLParser parseURL: aURLString.
> 
> StAX is more useful with XML than HTML, because XML documents can be huge.
> 
> > Sent: Tuesday, May 16, 2017 at 6:39 PM
> > From: PBKResearch 
> > To: "'Any question about pharo is welcome'" 
> > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] 
> > ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)
> >
> > Monty
> > 
> > Many thanks for your help. I have followed your advice to start again in a 
> > clean Moose 6.1 image, and so far everything is working fine. Apologies for 
> > getting you to sort out the results of my stupidity. In Pharo I am really 
> > an experienced beginner.
> > 
> > Thanks again
> > 
> > Peter Kenny
> > 
> > -Original Message-
> > From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> > monty
> > Sent: 16 May 2017 03:37
> > To: pharo-users@lists.pharo.org
> > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] 
> > ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)
> > 
> > Something went wrong during your upgrade with class initialization.
> > 
> > Installing the latest versions of these projects into a clean image would 
> > work, and so would installing the latest XMLParserHTML and XMLParserStAX 
> > into the newest Moose-6.1 image (which has the latest XMLParser and XPath).
> > 
> > But if you insist on upgrading your old image, try the latest 
> > ConfigurationOfXMLParser (.303.mcz) and ConfigurationOfXPath (.149.mcz) 
> > from their PharoExtras repos and install their latest project versions, and 
> > do the same with XMLParserHTML and XMLParserStAX (the older versions aren't 
> > compatible with newer XMLParser versions). Then open the test runner and 
> > run all "XML|XPath" tests. If you get any failures, evaluate this:
> > 
> > #('XML-Parser' 'XPath-Core') do: [:package |
> >