Re: [Pharo-dev] How to get rid of empty XML nodes?

[Stephane Ducasse]

Norbert

Should I say to the tool generating the XML that it is an idiot? Even
that I cannot. It is a tool I do not control.
I have no control about what I get.
Now why we cannot control that if people add a line return or not does
not matter?
Why I cannot be in charge of deciding? I take the risk of the
interpretation but now
the "standard" does not help me at all. It just tells me that is good for me.

I implemented in the past "standards" like XMI to found that there
were bugs in the spec.

At then end, each time I visit a node I have to check

visitNodeWithElements: aNodeWithElements
   | currentNode |
   currentNode := OkStubNode new.
   self cleanNode: aNodeWithElements.
   aNodeWithElements hasChildren
ifTrue: [ | tokenNode |
self cleanNode: aNodeWithElements nodes first.
tokenNode := self visitElement: aNodeWithElements
nodes first.
self assert: tokenNode isToken.
currentNode addChild: tokenNode.
aNodeWithElements nodes allButFirst
do: [ :each | currentNode addChild: (self
visitNodeWithElements: each) ] ].
^ currentNode

And I do not like to modify a structure while I'm visiting it.


cleanNode: aNodeWithElements
  aNodeWithElements removeNodes: (aNodeWithElements nodes select:
[ :e | e isStringNode and: [ e isEmpty or: [ e isWhitespace ] ] ])

So I understand why people are going away from XML.

Stef

On Fri, Dec 8, 2017 at 4:02 PM, Norbert Hartl  wrote:
>
>
>> Am 08.12.2017 um 14:21 schrieb Stephane Ducasse :
>>
>> Hi monty
>>
>>
>>> On Fri, Dec 8, 2017 at 9:03 AM, monty  wrote:
>>> By "empty XML nodes," do you mean whitespace-only string nodes?
>>
>> Yes
>>
>>> Those are included because all in-element whitespace is assumed significant 
>>> by the spec: https://www.w3.org/TR/xml/#sec-white-space
>>
>> I know. There was a discussion a while ago. I just lost a couple of
>> hours understanding that :(
>>
>> But this is a super super super annoying practices.
>> We had to test each nodes to see if it is a empty nodes so it makes
>> everything a lot more complex without real justification
>> beside the fact that these standardizers probably never implemented
>> some real cases.
>> This standard is a really out of reality from that perspective.
>
> Are you sure you do not oversimplify things? XML would be even more complex 
> if these cases would be in the standard. It is not easy to decide if a 
> whitespace is important or not.
> Where do this whitespaces in your case come from? Most probably because the 
> XML is pretty printed. That is inserting whitespaces into the serialized 
> text. So why not just stopping to pretty print and your problem is gone.
>
> Norbert
>>
>>> The exception is if the element is declared in the DTD as only having 
>>> element children ("element content"): 
>>> https://www.w3.org/TR/xml/#dt-elemcontent
>>
>> Well the XML files that I had (I did not choose XML because I would
>> have prefer JSON :) ), had no DTD :(
>>
>> So at the end of the day, this wonderful standard puts all the stress
>> and burden to people.
>>
>>>
>>> For example, if you declare an element like this:
>>>
>>> 
>>>
>>> Any whitespace around a "two," "three," or "four" element child of a "one" 
>>> element is insignificant and ignored (unless #preservesIgnorableWhitespace: 
>>> is true). Other parsers, like LibXML2 and Xerces, behave the same way.
>>>
>>> I'll see if I can come up with some easier way to deal with this, like an 
>>> optional parser setting, new enumeration methods, or maybe a tree 
>>> transformation.
>>
>> It would be A HUGE PLUS!!
>>
>>
>> Because reality is that people have XML files with just nodes and no
>> empty nodes and they are forced to
>> Let me know because I could try.
>>
>> I was showing how to use Pharo to import code to pharo learners and
>> this was a big drag.
>>
>> Stef
>>
>>
>> I tried to set some values in the parser but it did not work.
>> BTW I saw that the configuration logic forces to write the following
>>
>> | parser doc visitor |
>> parser := XMLDOMParser new
>>   on: self xmlContents;
>>   preservesIgnorableWhitespace: true.
>>
>> and not
>>
>> | parser doc visitor |
>> parser := XMLDOMParser new
>>preservesIgnorableWhitespace: true.
>>on: self xmlContents;
>>
>>
>>>
 Sent: Tuesday, December 05, 2017 at 8:29 AM
 From: "Stephane Ducasse" 
 To: "Pharo Development List" 
 Subject: [Pharo-dev] How to get rid of empty XML nodes?

 )Hi

 we are manipulating an XML document and I would like to get rid of the
 spurious empty string.
 We saw that the gt panes are doing it.

 (aNodeWithElements isStringNode
 and: [aNodeWithElements isEmpty
 or: [aNodeWithElements isWhitespace]]

 Is there a way not to produce empty nodes?
 Is there a simple way not to have to handle them

 Now each time we are dealing with a node with have to check.

Re: [Pharo-dev] Text Indentation in Pharo editor

[Stephane Ducasse]

I think so too.
Yesterday we got a crazy stuff spawning UI processes like hell.
In fact I have the impression that a crazy progress is running from
time to time.
I wonder if it is not linked to tests.

Stef

On Sat, Dec 9, 2017 at 7:48 AM, Norbert Hartl  wrote:
>
>
>> Am 08.12.2017 um 21:24 schrieb Tudor Girba :
>>
>> Hi Stef,
>>
>> Do you get the debugger issue even in a plain Pharo image?
>>
> I do
>
> Norbert
>> Doru
>>
>>
>>> On Dec 8, 2017, at 3:40 PM, Stephane Ducasse  
>>> wrote:
>>>
>>> I would love to have Ctrl E and Ctrl A.
>>> And yes we should not be different for the sake of it.
>>> For the moment the reason is simple: we are full of work and even more.
>>>
>>> FYI: I'm starting at regular crash of the VM and regular superbad
>>> behavior of the debugger (like hundred of debuggers, like spawing many
>>> process)
>>> there is a really bad problem there.
>>>
>>> Setf
>>>
 On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman  wrote:


> On 8 December 2017 at 11:37, Sean P. DeNigris  
> wrote:
>
> Torsten Bergmann wrote
>> so we do it with different shortcuts than regular editors
>
> I wonder if it makes sense to allow the standard shortcut. The current one
> is a bit like playing twister ;)


 We should be different if there is a good reason,
 but where possible (especially on UI interface) we should align with the
 majority.
 I feel this case is the latter.

 cheers -ben


>>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Don't give to get. Just give."
>

Re: [Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

[Henrik-Nergaard]

>>GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I 
cannot find the method.  
This is because it is implemented in RubScrollTextMorph.
GLMRubScrolledTextBrick implements #doesNotUnderstand: to send it to the
rubric object.
see:
https://pharo.fogbugz.com/f/cases/17888/GLMRubScrolledTextBrick-relies-on-dnu-delegation

Best regards,
Henrik



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

[Stephane Ducasse]

Hi

I'm working on 16969 https://pharo.fogbugz.com/f/cases/16969/
which is basically cleaning the use of rectangle instead of using
Margin. Now I'm surprised because
GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I
cannot find the method.  Did I misses something?

I rewrote it as


withoutMargins
self margins: (0@0) asMargin

but I'm still curious.

Stef

Re: [Pharo-dev] Two tables that share the same data source!?

[Stephane Ducasse]

Hi Elhamer

where can we find the code of the improvements you did on FastTable?

Stef

On Tue, Aug 8, 2017 at 2:42 AM, Elhamer  wrote:
> Hi Alex and thank you for your reply :))
>
> Good to know that bloc already supports that, I am definitely moving to work
> on/with it after that :))
>
> I've never encounter that scenario on a a Pharo package too, but since i was
> working on improving FTs, i thought why not!, besides, in apps with multiple
> tables, it might be handy to define a single large data source and assign
> columns to each table instead of defining a ds for each table, something
> like that:
>
> 
> |pane table1 table2 ds|
> ds:=FTCellSampleDataSource new:10.
> table1 := FTTableMorph new
> extent: 500@500;
> selectionMode: #column;
> addColumn: (FTColumn id: 'column1');
> addColumn: (FTColumn id: 'column2');
> addColumn: (FTColumn id: 'column6');
> dataSource: ds;
> selectRowIndex: 1;
> showFirstRowSelection;
> beMultipleSelection;
> yourself.
> table2 := FTTableMorph new
> extent: 500@500;
> selectionMode: #column;
> addColumn: (FTColumn id: 'column3');
> addColumn: (FTColumn id: 'column4');
> addColumn: (FTColumn id: 'column5');
> dataSource: ds;
> selectRowIndex: 1;
> showFirstRowSelection;
> beMultipleSelection;
> layoutInset: 10;
> yourself.
> pane := Morph new.
> pane layoutPolicy: TableLayout new.
> pane listDirection: #leftToRight.
> pane listCentering: #center.
> pane wrapCentering: #center.
> pane hResizing: #spaceFill.
> pane layoutInset: 10@10.
> pane cellInset:10@10.
> pane color: Color red.
>
> pane addMorph: table1.
> pane addMorph: table2.
> pane openInWindow .
>
> ```
>   
>
>
>
>
> --
> View this message in context: 
> http://forum.world.st/Two-tables-that-share-the-same-data-source-tp4959153p4959160.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

[Pharo-dev] metalink injection into closures ?

[Ben Coman]

When we execute this...

counter
"Greeter new counter"
| count |
count := 0.
[100 timesRepeat: [count := count + 1.
self inform: count + 1 printString.
2 seconds wait]] forkNamed: 'Count de Money'

and in the dubgger correct and save the code we normally get the message...
"Method for block not found on stack, can't edit and continue."

and I wonder if anything with Metalinks would facilitate inject
the corrected bytecode into the Process so that it oculd continue.

cheers -ben

[Pharo-dev] About margin and 16969

[Stephane Ducasse]

Hi henrik

I started to rescue your fix on wrong use of rectangle.
Then I noticed that you change the height of a margin.

We defined it as

height

^ self bottom + self top

Since we were considering that the height of a margin is the total
amount of space around.

and you as

height

^ self bottom - self top

Do you have a strong reason for that?

Stef