date:20150421


Le 21/04/2015 07:46, stepharo a écrit :



No, I changed MCMethodDefinition= to be more relaxed about
sources and treat two sources that differ only in leading/trailing
spaces as same. This way, these methods do not occur in merge tool
at all.
This is just a quick fix - much better would be to compare AST's and
treat whitespace-changes specially (i.e., provide a filter to show/hide
whitespace-only-changes).


OK now I wonder if we want to have methods with different end of line
conventions in the system.


I pushed a change to MCMethodDefinition#= a short while ago because 
source code was seeing line ending changes...


AST-based comparison would be nice there; however what about the cost? 
Some of MC operations are already fairly slow as they are now.


Thierry


I do not remember the discussion we got long time ago.

Stef

Do you think that we should integrate it?

Yes.


Stef

Le 20/4/15 12:36, Jan Vrany a écrit :

Hi,

I just wanted to merge some code in Monticello and the merge tool
marked all methods as conflict because their source differ in trailing
whitespace (newline). The diff panel on the right does not show any
difference.

http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVrany.1


Here's a fix for this particular problem in case somebody runs into the
same problem.

Best, Jan

Re: [Pharo-dev] missing packages in the Pharo50 repository

It means that we should also add the repositories of these projects so 
that MC can merge no?


Le 20/4/15 22:19, Esteban Lorenzano a écrit :

they are handled separately, through configurations.

cheers,
Esteban
  

On 20 Apr 2015, at 21:02, Pavel Krivanek pavel.kriva...@gmail.com wrote:

Hi,

these packages do not have a version in the Pharo50 repository:

Athens-Balloon
Athens-Cairo
Athens-CairoPools
Athens-Core
Athens-Examples
Athens-Morphic
Athens-Text
ConfigurationOfAthens
ConfigurationOfGlamourCore
ConfigurationOfGTInspectorCore
ConfigurationOfGToolkitCore
ConfigurationOfGTPlaygroundCore
ConfigurationOfGTSpotter
ConfigurationOfOSWindow
ConfigurationOfRubric
ConfigurationOfShoreLineReporter
ConfigurationOfTxText
ConfigurationOfVersionner
ConfigurationOfZincHTTPComponents
Glamour-Announcements
Glamour-Browsers
Glamour-Core
Glamour-Examples
Glamour-Helpers
Glamour-Morphic-Brick
Glamour-Morphic-Brick-Tests
Glamour-Morphic-Pager
Glamour-Morphic-Renderer
Glamour-Morphic-Theme
Glamour-Morphic-Widgets
Glamour-Presentations
Glamour-Rubric-Presentations
Glamour-Tests-Core
Glamour-Tests-Morphic
Glamour-Tests-Resources
Glamour-Tests-Rubric
GT-Inspector
GT-InspectorExtensions-Core
GT-Playground
GT-Spotter
GT-Spotter-EventRecorder
GT-SpotterExtensions-Core
GT-Tests-Inspector
GT-Tests-Playground
GT-Tests-Spotter
OSWindow-SDL2
OSWindow-VM
Rubric
ShoreLine-Report-Core
ShoreLine-Report-Settings
ShoreLine-Report-UI
TxText-AthensTests
TxText-Model
TxText-Styler
TxTextTests-Model
Versionner-Core-Commands
Versionner-Core-Model
Versionner-Spec-Browser
Versionner-Tests-Core-Model
Zinc-HTTP
Zinc-Character-Encoding-Core
Zinc-Character-Encoding-Tests
Zinc-Resource-Meta-Core
Zinc-Resource-Meta-Tests
Zinc-Tests
Zinc-Zodiac
Zodiac-Core
Zodiac-Tests

Cheers,
-- Pavel

Re: [Pharo-dev] missing packages in the Pharo50 repository


 On 21 Apr 2015, at 08:06, stepharo steph...@free.fr wrote:
 
 It means that we should also add the repositories of these projects so that 
 MC can merge no?
well, but you should not merge this projects :)

 
 Le 20/4/15 22:19, Esteban Lorenzano a écrit :
 they are handled separately, through configurations.
 
 cheers,
 Esteban
  
 On 20 Apr 2015, at 21:02, Pavel Krivanek pavel.kriva...@gmail.com wrote:
 
 Hi,
 
 these packages do not have a version in the Pharo50 repository:
 
 Athens-Balloon
 Athens-Cairo
 Athens-CairoPools
 Athens-Core
 Athens-Examples
 Athens-Morphic
 Athens-Text
 ConfigurationOfAthens
 ConfigurationOfGlamourCore
 ConfigurationOfGTInspectorCore
 ConfigurationOfGToolkitCore
 ConfigurationOfGTPlaygroundCore
 ConfigurationOfGTSpotter
 ConfigurationOfOSWindow
 ConfigurationOfRubric
 ConfigurationOfShoreLineReporter
 ConfigurationOfTxText
 ConfigurationOfVersionner
 ConfigurationOfZincHTTPComponents
 Glamour-Announcements
 Glamour-Browsers
 Glamour-Core
 Glamour-Examples
 Glamour-Helpers
 Glamour-Morphic-Brick
 Glamour-Morphic-Brick-Tests
 Glamour-Morphic-Pager
 Glamour-Morphic-Renderer
 Glamour-Morphic-Theme
 Glamour-Morphic-Widgets
 Glamour-Presentations
 Glamour-Rubric-Presentations
 Glamour-Tests-Core
 Glamour-Tests-Morphic
 Glamour-Tests-Resources
 Glamour-Tests-Rubric
 GT-Inspector
 GT-InspectorExtensions-Core
 GT-Playground
 GT-Spotter
 GT-Spotter-EventRecorder
 GT-SpotterExtensions-Core
 GT-Tests-Inspector
 GT-Tests-Playground
 GT-Tests-Spotter
 OSWindow-SDL2
 OSWindow-VM
 Rubric
 ShoreLine-Report-Core
 ShoreLine-Report-Settings
 ShoreLine-Report-UI
 TxText-AthensTests
 TxText-Model
 TxText-Styler
 TxTextTests-Model
 Versionner-Core-Commands
 Versionner-Core-Model
 Versionner-Spec-Browser
 Versionner-Tests-Core-Model
 Zinc-HTTP
 Zinc-Character-Encoding-Core
 Zinc-Character-Encoding-Tests
 Zinc-Resource-Meta-Core
 Zinc-Resource-Meta-Tests
 Zinc-Tests
 Zinc-Zodiac
 Zodiac-Core
 Zodiac-Tests
 
 Cheers,
 -- Pavel

Re: [Pharo-dev] [pharo-project/pharo-core] de6e0a: 50003

2015-04-21 Thread Marcus Denker


It had a comment:

Deprecated = use StartupPreferenceLoader

 On 21 Apr 2015, at 19:20, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
 
 So now startup actions are not working because StartupLoader was removed. 
 What are the plans about this?
 
 On 21 Apr 2015, at 17:40, GitHub nore...@github.com wrote:
 
 Branch: refs/heads/5.0
 Home:   https://github.com/pharo-project/pharo-core
 Commit: de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
 
 https://github.com/pharo-project/pharo-core/commit/de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
 Author: Jenkins Build Server bo...@pharo-project.org
 Date:   2015-04-21 (Tue, 21 Apr 2015)
 
 Changed paths:
   A AST-Core.package/NumberParser.class/class/testing/isNumber_.st
   A AST-Tests-Core.package/NumberParserTest.class/instance/tests - 
 Float/testIsNumber.st
   R Deprecated40.package/NBWin32Caret.class/README.md
   R Deprecated40.package/NBWin32Caret.class/class/accessing/getBlinkTime.st
   R Deprecated40.package/NBWin32Caret.class/definition.st
   R Deprecated40.package/NBWin32Menu.class/README.md
   R Deprecated40.package/NBWin32Menu.class/definition.st
   R Deprecated40.package/NBWin32MessageBox.class/README.md
   R Deprecated40.package/NBWin32MessageBox.class/class/instance 
 creation/messageBox_text_title_flags_.st
   R Deprecated40.package/NBWin32MessageBox.class/class/instance 
 creation/test.st
   R Deprecated40.package/NBWin32MessageBox.class/definition.st
   R Deprecated40.package/NBWin32Process.class/README.md
   R 
 Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcess.st
   R 
 Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st
   R Deprecated40.package/NBWin32Process.class/definition.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/accessing/getPriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st
   R Deprecated40.package/NBWin32ShellTest.class/README.md
   R Deprecated40.package/NBWin32ShellTest.class/definition.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st
   R Deprecated40.package/NBWin32Thread.class/README.md
   R 
 Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThread.st
   R 
 Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st
   R Deprecated40.package/NBWin32Thread.class/definition.st
   R 
 Deprecated40.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st
   R Deprecated40.package/Password.class/README.md
   R Deprecated40.package/Password.class/definition.st
   R Deprecated40.package/ShadowLabelMorph.class/README.md
   R Deprecated40.package/ShadowLabelMorph.class/definition.st
   R Deprecated40.package/ShadowLabelMorph.class/instance/drawing/drawOn_.st
   R Deprecated40.package/StartupLoader.class/README.md
   R Deprecated40.package/StartupLoader.class/class/accessing/default.st
   R Deprecated40.package/StartupLoader.class/definition.st
   R Deprecated40.package/TimeStamp.class/README.md
   R Deprecated40.package/TimeStamp.class/class/instance creation/now.st
   R Deprecated40.package/TimeStamp.class/class/instance creation/readFrom_.st
   R Deprecated40.package/TimeStamp.class/definition.st
   R Deprecated40.package/TimeStamp.class/instance/printing/printOn_.st
   R Deprecated40.package/TimeStamp.class/instance/squeak 
 protocol/asTimeStamp.st
   R Deprecated40.package/TimeStamp.class/instance/squeak protocol/species.st
   R Deprecated40.package/TimeStamp.class/instance/squeak protocol/storeOn_.st
   R 
 Deprecated40.package/extension/CheckBoxModel/instance/whenLabelChanged_.st
   R Deprecated40.package/extension/Class/instance/name_.st
   R Deprecated40.package/extension/CompiledMethod/instance/messagesDo_.st
   R Deprecated40.package/extension/Date/instance/leap.st
   R Deprecated40.package/extension/DateAndTime/instance/asTimeStamp.st
   R Deprecated40.package/extension/ImageModel/instance/whenActionChanged_.st
   R Deprecated40.package/extension/ImageModel/instance/whenImageChanged_.st
   R Deprecated40.package/extension/LabelModel/instance/text.st
   R Deprecated40.package/extension/LabelModel/instance/text_.st
   R Deprecated40.package/extension/LabelModel/instance/whenLabelChanged_.st
   R Deprecated40.package/extension/LabelModel/instance/whenTextChanged_.st
   R

Re: [Pharo-dev] Seaside One Click Experience on Pharo 4?

2015-04-21 Thread Paul DeBruicker

I'm against it without a commitment to also update all the docs that use the
one click. So its not just repackaging an image and vm into a one click
experience. Its a bigger task that will need weeks of work.

The docs are debugged and work. Seaside hasn't changed much. Pharo has
changed ... more. If the point of the Seaside docs is to learn Seaside then
what is there now is fine.

Dmitri Zagidulin wrote
Thanks, Torsten.
I will definitely include those instructions in whatever documentation I
can get my hands on.

But that's *in addition* to advocating that we update our Seaside
One-Click
experience image. (For the reasons that I outline earlier in this thread,
namely that the vast majority of existing docs (books, sites, blog posts)
point new users to the One-Click images.)

On Mon, Apr 20, 2015 at 3:48 PM, Torsten Bergmann lt;

astares@

gt; wrote:

Hi Dmitri,

not directly a one-click but in Pharo 4.0 you can load on your own:

- open World menu - Tools - Configuration Browser
- load Seaside directly (which as of today is Seaside 3.1.4)

After loading you can use Tools - Seaside control panel to add an
adaptor
(see attached screenshot) and then browse Seaside on the defined port
like
http://localhost:8080

If you like you can also load Bootstrap framework directly from the
config browser
- which is a wrapper for twitter bootstrap (see
http://pharo.pharocloud.com/bootstrap)

There is also work going on for a Seaside 3.2. Dont know about the
timeline.
Ideally you should ask on the seaside-dev list:

http://lists.squeakfoundation.org/pipermail/seaside-dev

Bye
T.

Gesendet: Montag, 20. April 2015 um 20:45 Uhr
Von: Dmitri Zagidulin lt;

dmitri@

gt;
An: Pharo Development List lt;

pharo-dev@.pharo

gt;
Betreff: Re: [Pharo-dev] Seaside One Click Experience on Pharo 4?

(Just wanting to make sure this issue doesn't get lost in the general 4.0
release activity and celebration).

What's a good place to open an issue, as a reminder/to-do item to create
a
Seaside+Pharo4 one-click image? The general Pharo fogbugz?

Or, who would be the people to talk to? (Sean? :) )

On Fri, Apr 10, 2015 at 3:10 PM, stepharo lt;

stepharo@

gt; wrote:
It should not be that complex:
putting the vm in the folder and the pharo 40 image + sources files.

Stef

Le 10/4/15 19:51, Dmitri Zagidulin a écrit :

Are there any plans to update the old Seaside One Click Experience for
Pharo 4.0 (and the latest stable Seaside)?

And if not, what would be the level of effort required? (And/or, who
would
be the people to talk to, to set it up?)

The reason I ask is, users new to web development on Pharo overwhelmingly
get recommended to use the One Click images.

- on
http://www.seaside.st/download/pharo[http://www.seaside.st/download/pharo]
-
The Seaside One-Click Experience is the easiest way to get started with
Seaside. Uses Pharo 1.4, I believe.

- Learning Web Development with Seaside 3 (
http://seaside.gemtalksystems.com/tutorial/chapter01.pdf[http://seaside.gemtalksystems.com/tutorial/chapter01.pdf]
)
also points to the Pharo download link above. Same deal, 1.4.

- Dynamic Web Development with Seaside (
http://book.seaside.st/book[http://book.seaside.st/book] ) also points to
the One-Click.

- Countless blog posts / tutorials link to it.

- And, finally, Updated Pharo By Example (the Seaside chapter), also
recommends the One Click image.

Given how much work the community has done since Pharo 1.4, would it not
make sense to update the integrated images?

--
View this message in context:
http://forum.world.st/Seaside-One-Click-Experience-on-Pharo-4-tp4818966p4820972.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Vm-dev] Fixes to the SqueakSSL Plugin


Thanks you guys!


Le 21/4/15 17:59, Tobias Pape a écrit :
  
Dear Smalltalkers


Starting with Levente Uzonyi's patches to the Linux version
of the SqueakSSL-Plugin, we (Marcel Taeumel and me) have
ported this to the OS X and Windows version as well.

Find three binaries[1] that can be used instead of
the ones found on versions found on SqueakSSL's google code
page.

SqueakSSL:
- x86 32bit Linux ELF dynamic library
- Contains Levente's SNI feature
   - needs SqueakSSL-ul.29 or equivalent for SNI support
   - can work without.
- NOT linked against OpenSSL, but
   _statically_ linked against LibreSSL 2.1.6 [2].
- It should work on older and newer Debian/Ubuntu as well as on
   CentOS/RedHat/SuSE systems.

SqueakSSL.dll
- x86 32bit Windows dll (built with Visual Studio 2013)
- Uses Schannel API
- SNI Support
   - needs SqueakSSL-ul.29 or equivalent for SNI support
   - can work without.
- setting an Int property via sqSetIntPropertySSL(...)
- Unicode problems when extracting the correct peerName in sqExtractPeerName

SqueakSSL.bundle
  - x86 32bit OS X Mach-O dylib (Linked against OS X 10.5 SDK)
  - Uses Security-Framework
  - SNI Support
   - needs SqueakSSL-ul.29 or equivalent for SNI support
   - can work without.
-

The changes necessary for Windows and OS X are not yet available in the
squeakvm svn, the linux ones are.
  I have not yet found a good way to include the static linking in either
the way the Autoconf works for Cog or CMake works for the interpreter,
but I'll follow-up to this.



Best regards
-Tobias




[1]: http://forum.world.st/file/n4820846/squeakssl.zip
[2]: http://www.libressl.org/

Re: [Pharo-dev] Roadmap

Aha! Good to know. Thanks :)

On Tue, Apr 21, 2015 at 1:37 PM, Sven Van Caekenberghe s...@stfx.eu wrote:


  On 21 Apr 2015, at 19:06, Peter Uhnák i.uh...@gmail.com wrote:
 
  On Mon, Apr 20, 2015 at 7:26 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:
  Similar question - are there any roadmap plans to add Dictionary
 literals to Pharo?
  You can already do things like
  { 'key' - 'value'. 'key2' - 'value2' } asDictionary

 YES !

 You could also write:

 { #foo-100. #bar-200 } asDictionary.
 { #foo-100. #bar-200 } asOrderedDictionary.
 { #foo-100. #bar-200 } asSmallDictionary.

 And everyone will know exactly what you mean, imagine that ;-)

Re: [Pharo-dev] Improving the documentation model

Funnily enough I am in the exact opposite opinion, of Graphical approach
being vastly superior to text based approach including programming
languages. 25 years using computers and coding with them and still cannot
fathom why programming languages are still a think and why developers and
power users rely so much on text based approach. But whether I like it or
not the coding world is dominated by text based solutions.

Its a pointless debate though when it comes to pharo will depend on the
people doing the work. Personally I don't have the time of going very deep
into this and doing all the hard work it requires. My focus is elsewhere.
But I welcome any contribution.

As a lawyer myself and a coder, I cannot even begin to compare Latex to the
convenience of Libreoffice I use at work. Its not even a debate .  Latex is
something I never heard of until  Pillar introduced me to it. Can't imagine
who in the right mind would use this to document things, but I guess they
have their reasons.

I started with command line and CP/M back in 1988 but even back then when
GUIs were not mainstream (at least in my country) I was dreaming of
graphical intefaces that would lift me from the restrictions of text based
approach and the dreaded command line. I wish I had found out about
Smalltalk back then and its elegant solution to this problem.

I love Pillar because its simple and I like the syntax, but yeah in the end
I would choose a Graphical Documentation Tool no questions asked.

On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
wrote:

 On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris s...@clipperadams.com
 wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


 Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

 You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter wins, no contest. (Now, that is not to say that text-based code
 editing can't be /improved/ with better IDE tools, that's what we're all
 about after all.)

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread p...@highoctane.be

Pillar is fine as long as we aren't forced into the backend quirks to get a
given output.

I haven't see Docbook and Docbook-XML and XSL-FO mentioned. But these are
working nicely too.

Lots of Linux docs are written with Docbook.

I've a client who outputs supercomplicated documents with XSL-FO.

A Pillar output to Docbook would be great.

One must invest time in any choice to be really productive. WYSIWYG
included.

FWIW LibreOffice equations are written much faster when one knows the text
based language than with the point and click tools.

The best thing is an ability to render fast. Same as Smalltalk: fast
feedback in order to iterate without a break in the flow.




Le 21 avr. 2015 20:03, kilon alios kilon.al...@gmail.com a écrit :

 Funnily enough I am in the exact opposite opinion, of Graphical approach
 being vastly superior to text based approach including programming
 languages. 25 years using computers and coding with them and still cannot
 fathom why programming languages are still a think and why developers and
 power users rely so much on text based approach. But whether I like it or
 not the coding world is dominated by text based solutions.

 Its a pointless debate though when it comes to pharo will depend on the
 people doing the work. Personally I don't have the time of going very deep
 into this and doing all the hard work it requires. My focus is elsewhere.
 But I welcome any contribution.

 As a lawyer myself and a coder, I cannot even begin to compare Latex to
 the convenience of Libreoffice I use at work. Its not even a debate .
 Latex is something I never heard of until  Pillar introduced me to it.
 Can't imagine who in the right mind would use this to document things, but
 I guess they have their reasons.

 I started with command line and CP/M back in 1988 but even back then when
 GUIs were not mainstream (at least in my country) I was dreaming of
 graphical intefaces that would lift me from the restrictions of text based
 approach and the dreaded command line. I wish I had found out about
 Smalltalk back then and its elegant solution to this problem.

 I love Pillar because its simple and I like the syntax, but yeah in the
 end I would choose a Graphical Documentation Tool no questions asked.

 On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:

 On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris s...@clipperadams.com
  wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


 Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

 You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter wins, no contest. (Now, that is not to say that text-based code
 editing can't be /improved/ with better IDE tools, that's what we're all
 about after all.)

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread p...@highoctane.be

On Tue, Apr 21, 2015 at 8:48 PM, Nicolas Anquetil nicolas.anque...@inria.fr
 wrote:


 This remind me of a discussion a very long time ago on a newsgroup

 - a young zealot of GUI (windows, buttons, mouses) was asking himself and
 the community how people could deny that this was the best interface on
 earth or how anybody could prefer text based interface

 - a seasonned sys. admin then started to explain all the clicks he had to
 perform to create one new user account. Result: for one new user some
 minutes of work
 He then added that he had to create HUMDREDS of user every year and was so
 very happy that he did not had to do it all by pointing and clicking but
 had some scripts to do it.

 So the answer to all this is that there are very good and valid reasons to
 prefer text to all the shiny interfaces of he world.
 And you don't even have to look very far to find some.

 As for programming with in a graphical way, the ability has been around
 for decades.
 I believe we can safely assume that if people are still using textual
 interface after such a very long period (in computer science time frame),
 it is most certainly because natural selection has favoured the choice that
 had most advantages ...


Coral, where are you?


 nicolas

 PS: which does not mean that GUI are completely useless

 On 21/04/2015 20:03, kilon alios wrote:

   Funnily enough I am in the exact opposite opinion, of Graphical
 approach being vastly superior to text based approach including programming
 languages. 25 years using computers and coding with them and still cannot
 fathom why programming languages are still a think and why developers and
 power users rely so much on text based approach. But whether I like it or
 not the coding world is dominated by text based solutions.

  Its a pointless debate though when it comes to pharo will depend on the
 people doing the work. Personally I don't have the time of going very deep
 into this and doing all the hard work it requires. My focus is elsewhere.
 But I welcome any contribution.

  As a lawyer myself and a coder, I cannot even begin to compare Latex to
 the convenience of Libreoffice I use at work. Its not even a debate .
 Latex is something I never heard of until  Pillar introduced me to it.
 Can't imagine who in the right mind would use this to document things, but
 I guess they have their reasons.

  I started with command line and CP/M back in 1988 but even back then when
 GUIs were not mainstream (at least in my country) I was dreaming of
 graphical intefaces that would lift me from the restrictions of text based
 approach and the dreaded command line. I wish I had found out about
 Smalltalk back then and its elegant solution to this problem.

  I love Pillar because its simple and I like the syntax, but yeah in the
 end I would choose a Graphical Documentation Tool no questions asked.

 On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:

  On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris 
 s...@clipperadams.com wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


  Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

  You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter wins, no contest. (Now, that is not to say that text-based code
 editing can't be /improved/ with better IDE tools, that's what we're all
 about after all.)

Re: [Pharo-dev] Interrupt a locked pharo image from outside


Le 21/04/2015 18:04, Sean P. DeNigris a écrit :

Thierry Goubier wrote

OSProcess 4.5.13 has a tendancy to lock the image on some linux systems


Total shot in the dark, but IIRC setting PipeableOSProcess output to non
blocking fixes many lockup scenarios


I believe downgrading OSProcess to 4.5.11 is making PipeableOSProcess 
use blocking I/O :) and it solves the lockup.


Thierry

Re: [Pharo-dev] Improving the documentation model

Its funny you mention natural selection an extremely stupid and slow
process. Fortunately for us software evolves with artificial selection
which way faster and way more intelligent. But still it comes with a great
deal of flaws when you take a look at what exactly is popular in the coding
world nowdays . Or even outside the coding world. But yes we can sit here
and debate this for million of years.

I am not a GUI zealot though, I have my own opinion that I never try to
enforce on others. I am perfectly ok with people that prefer a text based
approach. The only thing I am saying that GUIs have one undisputed
advantage, they are not text based only ;)

For me it comes down to making sensible convenient and practical useful
UIs. How you do it , graphical or text based is secondary concern.

I am also aware of the fact that GUIs tend to be more difficult to create,
which provides a very good explanation why command lines are still quite
popular.

On Tue, Apr 21, 2015 at 9:48 PM, Nicolas Anquetil nicolas.anque...@inria.fr
 wrote:


 This remind me of a discussion a very long time ago on a newsgroup

 - a young zealot of GUI (windows, buttons, mouses) was asking himself and
 the community how people could deny that this was the best interface on
 earth or how anybody could prefer text based interface

 - a seasonned sys. admin then started to explain all the clicks he had to
 perform to create one new user account. Result: for one new user some
 minutes of work
 He then added that he had to create HUMDREDS of user every year and was so
 very happy that he did not had to do it all by pointing and clicking but
 had some scripts to do it.

 So the answer to all this is that there are very good and valid reasons to
 prefer text to all the shiny interfaces of he world.
 And you don't even have to look very far to find some.

 As for programming with in a graphical way, the ability has been around
 for decades.
 I believe we can safely assume that if people are still using textual
 interface after such a very long period (in computer science time frame),
 it is most certainly because natural selection has favoured the choice that
 had most advantages ...

 nicolas

 PS: which does not mean that GUI are completely useless


 On 21/04/2015 20:03, kilon alios wrote:

   Funnily enough I am in the exact opposite opinion, of Graphical
 approach being vastly superior to text based approach including programming
 languages. 25 years using computers and coding with them and still cannot
 fathom why programming languages are still a think and why developers and
 power users rely so much on text based approach. But whether I like it or
 not the coding world is dominated by text based solutions.

  Its a pointless debate though when it comes to pharo will depend on the
 people doing the work. Personally I don't have the time of going very deep
 into this and doing all the hard work it requires. My focus is elsewhere.
 But I welcome any contribution.

  As a lawyer myself and a coder, I cannot even begin to compare Latex to
 the convenience of Libreoffice I use at work. Its not even a debate .
 Latex is something I never heard of until  Pillar introduced me to it.
 Can't imagine who in the right mind would use this to document things, but
 I guess they have their reasons.

  I started with command line and CP/M back in 1988 but even back then when
 GUIs were not mainstream (at least in my country) I was dreaming of
 graphical intefaces that would lift me from the restrictions of text based
 approach and the dreaded command line. I wish I had found out about
 Smalltalk back then and its elegant solution to this problem.

  I love Pillar because its simple and I like the syntax, but yeah in the
 end I would choose a Graphical Documentation Tool no questions asked.

 On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:

  On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris 
 s...@clipperadams.com wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


  Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

  You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter wins, no contest. (Now, that is not to say that text-based code
 editing can't be /improved/ with better IDE tools, that's what we're all
 about after all.)

Re: [Pharo-dev] [pharo-project/pharo-core] de6e0a: 50003

Oh, it should be replaced by StartupPreferencesLoader. I’ll submit a slice


 On 21 Apr 2015, at 19:20, Yuriy Tymchuk yuriy.tymc...@me.com wrote:
 
 So now startup actions are not working because StartupLoader was removed. 
 What are the plans about this?
 
 On 21 Apr 2015, at 17:40, GitHub nore...@github.com wrote:
 
 Branch: refs/heads/5.0
 Home:   https://github.com/pharo-project/pharo-core
 Commit: de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
 
 https://github.com/pharo-project/pharo-core/commit/de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
 Author: Jenkins Build Server bo...@pharo-project.org
 Date:   2015-04-21 (Tue, 21 Apr 2015)
 
 Changed paths:
   A AST-Core.package/NumberParser.class/class/testing/isNumber_.st
   A AST-Tests-Core.package/NumberParserTest.class/instance/tests - 
 Float/testIsNumber.st
   R Deprecated40.package/NBWin32Caret.class/README.md
   R Deprecated40.package/NBWin32Caret.class/class/accessing/getBlinkTime.st
   R Deprecated40.package/NBWin32Caret.class/definition.st
   R Deprecated40.package/NBWin32Menu.class/README.md
   R Deprecated40.package/NBWin32Menu.class/definition.st
   R Deprecated40.package/NBWin32MessageBox.class/README.md
   R Deprecated40.package/NBWin32MessageBox.class/class/instance 
 creation/messageBox_text_title_flags_.st
   R Deprecated40.package/NBWin32MessageBox.class/class/instance 
 creation/test.st
   R Deprecated40.package/NBWin32MessageBox.class/definition.st
   R Deprecated40.package/NBWin32Process.class/README.md
   R 
 Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcess.st
   R 
 Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st
   R Deprecated40.package/NBWin32Process.class/definition.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/accessing/getPriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st
   R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st
   R Deprecated40.package/NBWin32ShellTest.class/README.md
   R Deprecated40.package/NBWin32ShellTest.class/definition.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st
   R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st
   R Deprecated40.package/NBWin32Thread.class/README.md
   R 
 Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThread.st
   R 
 Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st
   R Deprecated40.package/NBWin32Thread.class/definition.st
   R 
 Deprecated40.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st
   R Deprecated40.package/Password.class/README.md
   R Deprecated40.package/Password.class/definition.st
   R Deprecated40.package/ShadowLabelMorph.class/README.md
   R Deprecated40.package/ShadowLabelMorph.class/definition.st
   R Deprecated40.package/ShadowLabelMorph.class/instance/drawing/drawOn_.st
   R Deprecated40.package/StartupLoader.class/README.md
   R Deprecated40.package/StartupLoader.class/class/accessing/default.st
   R Deprecated40.package/StartupLoader.class/definition.st
   R Deprecated40.package/TimeStamp.class/README.md
   R Deprecated40.package/TimeStamp.class/class/instance creation/now.st
   R Deprecated40.package/TimeStamp.class/class/instance creation/readFrom_.st
   R Deprecated40.package/TimeStamp.class/definition.st
   R Deprecated40.package/TimeStamp.class/instance/printing/printOn_.st
   R Deprecated40.package/TimeStamp.class/instance/squeak 
 protocol/asTimeStamp.st
   R Deprecated40.package/TimeStamp.class/instance/squeak protocol/species.st
   R Deprecated40.package/TimeStamp.class/instance/squeak protocol/storeOn_.st
   R 
 Deprecated40.package/extension/CheckBoxModel/instance/whenLabelChanged_.st
   R Deprecated40.package/extension/Class/instance/name_.st
   R Deprecated40.package/extension/CompiledMethod/instance/messagesDo_.st
   R Deprecated40.package/extension/Date/instance/leap.st
   R Deprecated40.package/extension/DateAndTime/instance/asTimeStamp.st
   R Deprecated40.package/extension/ImageModel/instance/whenActionChanged_.st
   R Deprecated40.package/extension/ImageModel/instance/whenImageChanged_.st
   R Deprecated40.package/extension/LabelModel/instance/text.st
   R Deprecated40.package/extension/LabelModel/instance/text_.st
   R Deprecated40.package/extension/LabelModel/instance/whenLabelChanged_.st
   R Deprecated40.package/extension/LabelModel/instance/whenTextChanged_.st
   R

Re: [Pharo-dev] Roadmap

2015-04-21 Thread Sven Van Caekenberghe


 On 21 Apr 2015, at 19:06, Peter Uhnák i.uh...@gmail.com wrote:
 
 On Mon, Apr 20, 2015 at 7:26 PM, Dmitri Zagidulin dmi...@zagidulin.net 
 wrote:
 Similar question - are there any roadmap plans to add Dictionary literals to 
 Pharo?
 You can already do things like
 { 'key' - 'value'. 'key2' - 'value2' } asDictionary

YES !

You could also write:

{ #foo-100. #bar-200 } asDictionary.
{ #foo-100. #bar-200 } asOrderedDictionary.
{ #foo-100. #bar-200 } asSmallDictionary.

And everyone will know exactly what you mean, imagine that ;-)

Re: [Pharo-dev] [pharo-project/pharo-core] de6e0a: 50003

So now startup actions are not working because StartupLoader was removed. What 
are the plans about this?

 On 21 Apr 2015, at 17:40, GitHub nore...@github.com wrote:
 
  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
  
 https://github.com/pharo-project/pharo-core/commit/de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
  Author: Jenkins Build Server bo...@pharo-project.org
  Date:   2015-04-21 (Tue, 21 Apr 2015)
 
  Changed paths:
A AST-Core.package/NumberParser.class/class/testing/isNumber_.st
A AST-Tests-Core.package/NumberParserTest.class/instance/tests - 
 Float/testIsNumber.st
R Deprecated40.package/NBWin32Caret.class/README.md
R Deprecated40.package/NBWin32Caret.class/class/accessing/getBlinkTime.st
R Deprecated40.package/NBWin32Caret.class/definition.st
R Deprecated40.package/NBWin32Menu.class/README.md
R Deprecated40.package/NBWin32Menu.class/definition.st
R Deprecated40.package/NBWin32MessageBox.class/README.md
R Deprecated40.package/NBWin32MessageBox.class/class/instance 
 creation/messageBox_text_title_flags_.st
R Deprecated40.package/NBWin32MessageBox.class/class/instance 
 creation/test.st
R Deprecated40.package/NBWin32MessageBox.class/definition.st
R Deprecated40.package/NBWin32Process.class/README.md
R 
 Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcess.st
R 
 Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st
R Deprecated40.package/NBWin32Process.class/definition.st
R 
 Deprecated40.package/NBWin32Process.class/instance/accessing/getPriorityClass.st
R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st
R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st
R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st
R 
 Deprecated40.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st
R Deprecated40.package/NBWin32ShellTest.class/README.md
R Deprecated40.package/NBWin32ShellTest.class/definition.st
R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st
R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st
R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st
R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st
R 
 Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st
R Deprecated40.package/NBWin32Thread.class/README.md
R 
 Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThread.st
R 
 Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st
R Deprecated40.package/NBWin32Thread.class/definition.st
R 
 Deprecated40.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st
R Deprecated40.package/Password.class/README.md
R Deprecated40.package/Password.class/definition.st
R Deprecated40.package/ShadowLabelMorph.class/README.md
R Deprecated40.package/ShadowLabelMorph.class/definition.st
R Deprecated40.package/ShadowLabelMorph.class/instance/drawing/drawOn_.st
R Deprecated40.package/StartupLoader.class/README.md
R Deprecated40.package/StartupLoader.class/class/accessing/default.st
R Deprecated40.package/StartupLoader.class/definition.st
R Deprecated40.package/TimeStamp.class/README.md
R Deprecated40.package/TimeStamp.class/class/instance creation/now.st
R Deprecated40.package/TimeStamp.class/class/instance creation/readFrom_.st
R Deprecated40.package/TimeStamp.class/definition.st
R Deprecated40.package/TimeStamp.class/instance/printing/printOn_.st
R Deprecated40.package/TimeStamp.class/instance/squeak 
 protocol/asTimeStamp.st
R Deprecated40.package/TimeStamp.class/instance/squeak protocol/species.st
R Deprecated40.package/TimeStamp.class/instance/squeak protocol/storeOn_.st
R 
 Deprecated40.package/extension/CheckBoxModel/instance/whenLabelChanged_.st
R Deprecated40.package/extension/Class/instance/name_.st
R Deprecated40.package/extension/CompiledMethod/instance/messagesDo_.st
R Deprecated40.package/extension/Date/instance/leap.st
R Deprecated40.package/extension/DateAndTime/instance/asTimeStamp.st
R Deprecated40.package/extension/ImageModel/instance/whenActionChanged_.st
R Deprecated40.package/extension/ImageModel/instance/whenImageChanged_.st
R Deprecated40.package/extension/LabelModel/instance/text.st
R Deprecated40.package/extension/LabelModel/instance/text_.st
R Deprecated40.package/extension/LabelModel/instance/whenLabelChanged_.st
R Deprecated40.package/extension/LabelModel/instance/whenTextChanged_.st
R Deprecated40.package/extension/Locale/class/addLocalChangedListener_.st
R

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread nacho

The other day I was thinking about this. I thought that it would be a great
idea to have a pillar rendering engine inside Pharo.
In that way the documentation written will be available in the image
WYSIWYG with no need for recompilation. The update of books will be easy,
just do a Software Update and the documentation is up to date.
a Pillar rendering, WYSIWYG editor would be great.
cheers
Nacho

*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*

On Tue, Apr 21, 2015 at 2:49 PM, kilon.alios [via Smalltalk]
ml-node+s1294792n4820973...@n4.nabble.com wrote:

Funnily enough I am in the exact opposite opinion, of Graphical approach
being vastly superior to text based approach including programming
languages. 25 years using computers and coding with them and still cannot
fathom why programming languages are still a think and why developers and
power users rely so much on text based approach. But whether I like it or
not the coding world is dominated by text based solutions.

Its a pointless debate though when it comes to pharo will depend on the
people doing the work. Personally I don't have the time of going very deep
into this and doing all the hard work it requires. My focus is elsewhere.
But I welcome any contribution.

As a lawyer myself and a coder, I cannot even begin to compare Latex to
the convenience of Libreoffice I use at work. Its not even a debate .
Latex is something I never heard of until Pillar introduced me to it.
Can't imagine who in the right mind would use this to document things, but
I guess they have their reasons.

I started with command line and CP/M back in 1988 but even back then when
GUIs were not mainstream (at least in my country) I was dreaming of
graphical intefaces that would lift me from the restrictions of text based
approach and the dreaded command line. I wish I had found out about
Smalltalk back then and its elegant solution to this problem.

I love Pillar because its simple and I like the syntax, but yeah in the
end I would choose a Graphical Documentation Tool no questions asked.

On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin [hidden email]
http:///user/SendEmail.jtp?type=nodenode=4820973i=0 wrote:

On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris [hidden email]
http:///user/SendEmail.jtp?type=nodenode=4820973i=1 wrote:

I dream that all documents in my Dynabook are WYSIWYG. However, the
computing world seems to have regressed into writing documents in various
forms of assembly code.

Completely disagree, that it's a regression in any way :) Text-based
document writing has enabled so many more features than WYSIWYG approaches
have ever dreamed of. I would be happy to debate the merits of the two
approaches, feature-for-feature.

You're basically pining for the equivalent of VisualBasic drag drop
programming, versus the flexibility of writing code in an editor. The
latter wins, no contest. (Now, that is not to say that text-based code
editing can't be /improved/ with better IDE tools, that's what we're all
about after all.)

--
If you reply to this email, your message will be added to the discussion
below:

http://forum.world.st/Improving-the-documentation-model-tp4820814p4820973.html
To start a new topic under Pharo Smalltalk Developers, email
ml-node+s1294792n1294837...@n4.nabble.com
To unsubscribe from Pharo Smalltalk Developers, click here
http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=1294837code=MDgwMG5hY2hvQGdtYWlsLmNvbXwxMjk0ODM3fC0xOTAxMTExODEy
.
NAML
http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml

-
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context:
http://forum.world.st/Improving-the-documentation-model-tp4820814p4820976.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread Nicolas Anquetil



This remind me of a discussion a very long time ago on a newsgroup

- a young zealot of GUI (windows, buttons, mouses) was asking himself 
and the community how people could deny that this was the best interface 
on earth or how anybody could prefer text based interface


- a seasonned sys. admin then started to explain all the clicks he had 
to perform to create one new user account. Result: for one new user some 
minutes of work
He then added that he had to create HUMDREDS of user every year and was 
so very happy that he did not had to do it all by pointing and clicking 
but had some scripts to do it.


So the answer to all this is that there are very good and valid reasons 
to prefer text to all the shiny interfaces of he world.

And you don't even have to look very far to find some.

As for programming with in a graphical way, the ability has been around 
for decades.
I believe we can safely assume that if people are still using textual 
interface after such a very long period (in computer science time 
frame), it is most certainly because natural selection has favoured the 
choice that had most advantages ...


nicolas

PS: which does not mean that GUI are completely useless

On 21/04/2015 20:03, kilon alios wrote:
Funnily enough I am in the exact opposite opinion, of Graphical 
approach being vastly superior to text based approach including 
programming languages. 25 years using computers and coding with them 
and still cannot fathom why programming languages are still a think 
and why developers and power users rely so much on text based 
approach. But whether I like it or not the coding world is dominated 
by text based solutions.


Its a pointless debate though when it comes to pharo will depend on 
the people doing the work. Personally I don't have the time of going 
very deep into this and doing all the hard work it requires. My focus 
is elsewhere. But I welcome any contribution.


As a lawyer myself and a coder, I cannot even begin to compare Latex 
to the convenience of Libreoffice I use at work. Its not even a debate 
.  Latex is something I never heard of until  Pillar introduced me to 
it. Can't imagine who in the right mind would use this to document 
things, but I guess they have their reasons.


I started with command line and CP/M back in 1988 but even back then 
when GUIs were not mainstream (at least in my country) I was dreaming 
of graphical intefaces that would lift me from the restrictions of 
text based approach and the dreaded command line. I wish I had found 
out about Smalltalk back then and its elegant solution to this problem.


I love Pillar because its simple and I like the syntax, but yeah in 
the end I would choose a Graphical Documentation Tool no questions asked.


On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin 
dmi...@zagidulin.net mailto:dmi...@zagidulin.net wrote:


On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris
s...@clipperadams.com mailto:s...@clipperadams.com wrote:

I dream that all documents in my Dynabook are WYSIWYG.
However, the
computing world seems to have regressed into writing documents
in various
forms of assembly code.


Completely disagree, that it's a regression in any way :)
 Text-based document writing has enabled so many more features
than WYSIWYG approaches have ever dreamed of. I would be happy to
debate the merits of the two approaches, feature-for-feature.

You're basically pining for the equivalent of VisualBasic drag 
drop programming, versus the flexibility of writing code in an
editor. The latter wins, no contest. (Now, that is not to say that
text-based code editing can't be /improved/ with better IDE tools,
that's what we're all about after all.)

Re: [Pharo-dev] missing packages in the Pharo50 repository

2015-04-21 11:49 GMT+02:00 Esteban Lorenzano esteba...@gmail.com:


 On 21 Apr 2015, at 11:42, Ben Coman b...@openinworld.com wrote:

 btw, how do you merge Configurations?  For example, if I fix something X
 in my image and continue to work in it a month while the Image
 Configurations move forward, how do avoid losing that fix when I update to
 the latest Configuration ?


 you *do not* merge configurations.
 if you fix  something in a configured project, you submit your change to
 proper repository (not as a SLICE, as regular packages), which in time will
 be included (or not, if project owner rejects it) in a new configutation
 that will be included in Pharo.


The problem is that the configuration of the project used to version that
project inside the Pharo image isn't versionned inside Pharo, but instead
in the project itself.

So, on a regular basis, you have a message which says: I tried to load the
project X inside Pharo (where X, as an older version, is inside Pharo
already) and it breaks here and there.

It will bite us when we'll try to make use of the Minimal image and rebuilt
stuff on top of it; all those external projects have a tendency to redefine
their configurations and semantic versions on a regular basis, and Pharo
does not record where and which; which will make reproducing out of a
Minimal image a real pain, with breakages appearing from one day to another.



 that's how any complex project works... and that's how we should work too.
 SLICES are just a patch that exists because our system still not modular
 enough.


Well, current system isn't much better, IMHO.

A simple solution, would be to version in PharoXX/main, the exact
configuration used to load the external project.

It is not the case today.

Thierry




 Actually I guess it would be useful if a Configuration could be merged
 with the same GUI that merges a Slice.


 well... monkey and integrator app (integrators use it) does the proper
 loading.
 But I insist: configurations are not merged: versions are loaded, instead.

 cheers.
 Esteban


 cheers -ben

 On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano esteba...@gmail.com
 wrote:


  On 21 Apr 2015, at 08:06, stepharo steph...@free.fr wrote:
 
  It means that we should also add the repositories of these projects so
 that MC can merge no?
 well, but you should not merge this projects :)

 
  Le 20/4/15 22:19, Esteban Lorenzano a écrit :
  they are handled separately, through configurations.
 
  cheers,
  Esteban
 
  On 20 Apr 2015, at 21:02, Pavel Krivanek pavel.kriva...@gmail.com
 wrote:
 
  Hi,
 
  these packages do not have a version in the Pharo50 repository:
 
  Athens-Balloon
  Athens-Cairo
  Athens-CairoPools
  Athens-Core
  Athens-Examples
  Athens-Morphic
  Athens-Text
  ConfigurationOfAthens
  ConfigurationOfGlamourCore
  ConfigurationOfGTInspectorCore
  ConfigurationOfGToolkitCore
  ConfigurationOfGTPlaygroundCore
  ConfigurationOfGTSpotter
  ConfigurationOfOSWindow
  ConfigurationOfRubric
  ConfigurationOfShoreLineReporter
  ConfigurationOfTxText
  ConfigurationOfVersionner
  ConfigurationOfZincHTTPComponents
  Glamour-Announcements
  Glamour-Browsers
  Glamour-Core
  Glamour-Examples
  Glamour-Helpers
  Glamour-Morphic-Brick
  Glamour-Morphic-Brick-Tests
  Glamour-Morphic-Pager
  Glamour-Morphic-Renderer
  Glamour-Morphic-Theme
  Glamour-Morphic-Widgets
  Glamour-Presentations
  Glamour-Rubric-Presentations
  Glamour-Tests-Core
  Glamour-Tests-Morphic
  Glamour-Tests-Resources
  Glamour-Tests-Rubric
  GT-Inspector
  GT-InspectorExtensions-Core
  GT-Playground
  GT-Spotter
  GT-Spotter-EventRecorder
  GT-SpotterExtensions-Core
  GT-Tests-Inspector
  GT-Tests-Playground
  GT-Tests-Spotter
  OSWindow-SDL2
  OSWindow-VM
  Rubric
  ShoreLine-Report-Core
  ShoreLine-Report-Settings
  ShoreLine-Report-UI
  TxText-AthensTests
  TxText-Model
  TxText-Styler
  TxTextTests-Model
  Versionner-Core-Commands
  Versionner-Core-Model
  Versionner-Spec-Browser
  Versionner-Tests-Core-Model
  Zinc-HTTP
  Zinc-Character-Encoding-Core
  Zinc-Character-Encoding-Tests
  Zinc-Resource-Meta-Core
  Zinc-Resource-Meta-Tests
  Zinc-Tests
  Zinc-Zodiac
  Zodiac-Core
  Zodiac-Tests
 
  Cheers,
  -- Pavel

Re: [Pharo-dev] missing packages in the Pharo50 repository


 On 21 Apr 2015, at 12:52, Thierry Goubier thierry.goub...@gmail.com wrote:
 
 
 
 2015-04-21 11:49 GMT+02:00 Esteban Lorenzano esteba...@gmail.com 
 mailto:esteba...@gmail.com:
 
 On 21 Apr 2015, at 11:42, Ben Coman b...@openinworld.com 
 mailto:b...@openinworld.com wrote:
 
 btw, how do you merge Configurations?  For example, if I fix something X 
 in my image and continue to work in it a month while the Image 
 Configurations move forward, how do avoid losing that fix when I update to 
 the latest Configuration ?
 
 you *do not* merge configurations. 
 if you fix  something in a “configured” project, you submit your change to 
 proper repository (not as a SLICE, as regular packages), which in time will 
 be included (or not, if “project owner” rejects it) in a new configutation 
 that will be included in Pharo. 
 
 The problem is that the configuration of the project used to version that 
 project inside the Pharo image isn't versionned inside Pharo, but instead in 
 the project itself.
 
 So, on a regular basis, you have a message which says: I tried to load the 
 project X inside Pharo (where X, as an older version, is inside Pharo 
 already) and it breaks here and there.
 
 It will bite us when we'll try to make use of the Minimal image and rebuilt 
 stuff on top of it; all those external projects have a tendency to redefine 
 their configurations and semantic versions on a regular basis, and Pharo does 
 not record where and which; which will make reproducing out of a Minimal 
 image a real pain, with breakages appearing from one day to another.
  
 
 that’s how any complex project works… and that’s how we should work too. 
 SLICES are just a patch that exists because our system still not modular 
 enough.

configurations have versions. 
the problem is that I made a mistake and I allowed people to express their 
integrable versions as “#development”… while is easier for them, it proved to 
be a problem because it breaks update process. 
So, solution is simple: no “symbolic” version will be allowed to be integrated: 
just fixed number versions. 
Then update process will know which package versions to load. 


 
 Well, current system isn't much better, IMHO.

believe me, it is. 
would be better if system would be modular so we do not need to change 
everything to change a bit… but we’ll arrive there. 

 
 A simple solution, would be to version in PharoXX/main, the exact 
 configuration used to load the external project.

nope, solution is to explicit version to load :)

Esteban

 
 It is not the case today.
 
 Thierry
  
 
 
 Actually I guess it would be useful if a Configuration could be merged with 
 the same GUI that merges a Slice.
 
 well… monkey and integrator app (integrators use it) does the proper loading. 
 But I insist: configurations are not merged: versions are loaded, instead. 
 
 cheers. 
 Esteban
 
 
 cheers -ben
 
 On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano esteba...@gmail.com 
 mailto:esteba...@gmail.com wrote:
 
  On 21 Apr 2015, at 08:06, stepharo steph...@free.fr 
  mailto:steph...@free.fr wrote:
 
  It means that we should also add the repositories of these projects so 
  that MC can merge no?
 well, but you should not merge this projects :)
 
 
  Le 20/4/15 22:19, Esteban Lorenzano a écrit :
  they are handled separately, through configurations.
 
  cheers,
  Esteban
 
  On 20 Apr 2015, at 21:02, Pavel Krivanek pavel.kriva...@gmail.com 
  mailto:pavel.kriva...@gmail.com wrote:
 
  Hi,
 
  these packages do not have a version in the Pharo50 repository:
 
  Athens-Balloon
  Athens-Cairo
  Athens-CairoPools
  Athens-Core
  Athens-Examples
  Athens-Morphic
  Athens-Text
  ConfigurationOfAthens
  ConfigurationOfGlamourCore
  ConfigurationOfGTInspectorCore
  ConfigurationOfGToolkitCore
  ConfigurationOfGTPlaygroundCore
  ConfigurationOfGTSpotter
  ConfigurationOfOSWindow
  ConfigurationOfRubric
  ConfigurationOfShoreLineReporter
  ConfigurationOfTxText
  ConfigurationOfVersionner
  ConfigurationOfZincHTTPComponents
  Glamour-Announcements
  Glamour-Browsers
  Glamour-Core
  Glamour-Examples
  Glamour-Helpers
  Glamour-Morphic-Brick
  Glamour-Morphic-Brick-Tests
  Glamour-Morphic-Pager
  Glamour-Morphic-Renderer
  Glamour-Morphic-Theme
  Glamour-Morphic-Widgets
  Glamour-Presentations
  Glamour-Rubric-Presentations
  Glamour-Tests-Core
  Glamour-Tests-Morphic
  Glamour-Tests-Resources
  Glamour-Tests-Rubric
  GT-Inspector
  GT-InspectorExtensions-Core
  GT-Playground
  GT-Spotter
  GT-Spotter-EventRecorder
  GT-SpotterExtensions-Core
  GT-Tests-Inspector
  GT-Tests-Playground
  GT-Tests-Spotter
  OSWindow-SDL2
  OSWindow-VM
  Rubric
  ShoreLine-Report-Core
  ShoreLine-Report-Settings
  ShoreLine-Report-UI
  TxText-AthensTests
  TxText-Model
  TxText-Styler
  TxTextTests-Model
  Versionner-Core-Commands
  Versionner-Core-Model
  Versionner-Spec-Browser
  Versionner-Tests-Core-Model
  Zinc-HTTP
  Zinc-Character-Encoding-Core
  Zinc-Character-Encoding-Tests

Re: [Pharo-dev] TDD and BDD

2015-04-21 Thread Miguel Moquillon


Hi,

BDD and TDD stands for different purposes with different actors.
In BDD, stakeholders work on the functionalities of software units 
(coarse grain, black-box approach) whereas on TDD developers work on the 
object's features (fine-grain, white-box approach) that made the 
functionalities. So, the tooling in BDD should be different of the 
tooling used in TDD (BDD is more high-level than TDD).


In BDD each functionalities are describes as :

As a role
I want some feature
So that I gain a benefit

And the functionality is described in different scenarios (nominal and 
error ones) :

Given some initial context
When an event occurs
Then ensure some outcomes

Basic example:

/As a/ customer,
/I want/ to withdraw cash from an ATM,
/so that/ I don’t have to wait in line at the bank.

Scenario 1: Account is in credit
/Given/ the account is in credit
/And/ the card is valid
/And/ the dispenser contains cash
/When/ the customer requests cash
/Then/ ensure the account is debited
/And/ ensure cash is dispensed
/And/ ensure the card is returned

In fact, a useful and good BDD tool must provide :

 * a way to define a set of initial data
 * a DSL to define the functionalities and for each of them to express
   the scenarios according to the schema above
 * an engine that feeds automatically the scenario from the data set
   and that outputs the result.

Miguel Moquillon

Le 20/04/2015 12:02, Christophe Demarey a écrit :

Hi,

With BDD a current test practice is to start method names with 'should'.
It is not yet possible in Pharo but easily do-able (update of TestCase and some 
Nautilus methods).
I would like that Pharo detects tes methods all methods of a class subclassing 
(directly or not) TestCase AND starting with either 'test' or 'should'.
I also would like to add 'deny' to not use 'shouldNot' but here I'm not sure.

WDYT?

Christophe.

Re: [Pharo-dev] TDD and BDD


Le 20 avr. 2015 à 18:23, Sean P. DeNigris a écrit :

 Sean P. DeNigris wrote
 refactor so that all those places use one implementation somewhere.
 
 In fact, searching the sources for beginsWith: 'test', the logic is
 duplicated quite a bit. And someone even snuck your proposed change into
 CompiledMethod#isTestMethod, so now we already have two conflicting
 concepts of what a test selector is in Core.

In fact, I already did the changes in an image (but not published, I wait for 
feedback) and I also noticed the duplicated logic.
Monty also pointed me to take care of this problem: 
https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-tests-and-tries-to-run-them-TestRunner-doesn-t.

What I did is really simple:
In TestCase Class,
add 

update #testSelectors and #methodChanged: to use #isTestSelector:
update shouldInheritSelectors to fix a wrong behavior
In ClassTestCase, update selectorsTested to use  #isTestSelector:
Update Nautilus extension method CompiledMethodisTestMethod to use 
TestCase#isTestSelector:

I will add a slice for that but I'm not sure if it is a good idea to include 
tests beginning with deny.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] verveinJ cannot create mse with too big input

2015-04-21 Thread Nicolas Anquetil



it is a know fact, not an error :-)

Basically, verveinej has to maintain several models of the project in 
memory to be able to do its job
if the project is too big, this might end up exploding the memory and 
giving unexpected results


That's why we implemented the incremental parsing option

Now, what you are reporting looks like a bug, but because of the 
conditions, I am not sure it is really one, especially if it works fine 
when you split the project in 2


You also have the option of twicking the calling script to increase java 
memory
In the past, (sun) java used to require contiguous memory (just like 
pharo) but jikes removed this constraint
I believe the new oracle java removed the constraint also, so you might 
be able to go pretty high in memory on a java execution ...


Let us know if it works

nicolas

PS: This seems like a Moose-dev question rather than a pharo-dev one


On 21/04/2015 10:21, Fabrizio Perin wrote:

Hello,
I was trying to create an MSE file with VerveinJ and I got an 
incomplete MSE at the following error on the console:


/Exception while Visiting famix repository entities. For example, this 
might happen when an entity inside the repository has a property 
refering to an entity outside the repository/
/  Entity ID: 69580 (a FAMIX.AnnotationInstanceAttribute), property: 
parentAnnotationInstance/
/Exception in thread main java.lang.NoClassDefFoundError: 
fr/inria/verveine/core/gen/famix/NamedEntity/
/at 
ch.akuhn.fame.internal.RepositoryVisitor.acceptElement(RepositoryVisitor.java:111)/
/at 
ch.akuhn.fame.internal.RepositoryVisitor.acceptVisitor(RepositoryVisitor.java:162)/
/at 
ch.akuhn.fame.internal.RepositoryVisitor.run(RepositoryVisitor.java:207)/

/at ch.akuhn.fame.Repository.accept(Repository.java:105)/
/at ch.akuhn.fame.Repository.exportMSE(Repository.java:216)/
/at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown 
Source)/
/at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown 
Source)/
/at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown 
Source)/
/at 
eu.synectique.verveine.extractor.java.VerveineJParser.main(Unknown 
Source)/
/Caused by: java.lang.ClassNotFoundException: 
fr.inria.verveine.core.gen.famix.NamedEntity/

/at java.net.URLClassLoader$1.run(URLClassLoader.java:366)/
/at java.net.URLClassLoader$1.run(URLClassLoader.java:355)/
/at java.security.AccessController.doPrivileged(Native Method)/
/at java.net.URLClassLoader.findClass(URLClassLoader.java:354)/
/at java.lang.ClassLoader.loadClass(ClassLoader.java:423)/
/at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)/
/at java.lang.ClassLoader.loadClass(ClassLoader.java:356)/
/... 9 more /
/
/
/
/
I'm using windows, not sure how to get the version of verveinJ. The 
same does not happen if I split the project in two parts and I parse 
them separately.


Is it known error or am I doing something wrong?

Thanks in advance,
Fabrizio

Re: [Pharo-dev] TDD and BDD

2015-04-21 Thread Sven Van Caekenberghe


 On 21 Apr 2015, at 10:36, Christophe Demarey christophe.dema...@inria.fr 
 wrote:
 
 To come back to my proposition, it is just a first step to BDD to not prevent 
 people to define tests with something like 
 shouldAccountBalanceBePositiveAfterEachOperation (more behavior driven) 
 rather than testMyWonderfulMethod that may leads people to test the 
 implementation details and not the expected behavior.

Not that your naming ideas are bad, but right now you can write

testAccountShouldBePositiveAfterEachOperation

which is not that bad

Re: [Pharo-dev] missing packages in the Pharo50 repository


 On 21 Apr 2015, at 14:37, Stephan Eggermont step...@stack.nl wrote:
 
 On 21/04/15 13:14, Esteban Lorenzano wrote:
 
 nope, solution is to explicit version to load :)
 
 Explicit symbolic version, that is.
 Never a fixed number, as that can't be patched.
 That breaks the update process just as well.

no… explicit fixed number. I need version 1.0.42, not #stable or 
#myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42
And of course can be patched…. with version 1.0.43. 
That’s the only way to be able to make the update process work. 

Esteban

 
 Stephan

Re: [Pharo-dev] missing packages in the Pharo50 repository

2015-04-21 Thread Norbert Hartl


 Am 21.04.2015 um 14:53 schrieb Esteban Lorenzano esteba...@gmail.com:
 
 
 On 21 Apr 2015, at 14:37, Stephan Eggermont step...@stack.nl wrote:
 
 On 21/04/15 13:14, Esteban Lorenzano wrote:
 
 nope, solution is to explicit version to load :)
 
 Explicit symbolic version, that is.
 Never a fixed number, as that can't be patched.
 That breaks the update process just as well.
 
 no… explicit fixed number. I need version 1.0.42, not #stable or 
 #myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42
 And of course can be patched…. with version 1.0.43. 
 That’s the only way to be able to make the update process work. 
 
+1

Norbert

Re: [Pharo-dev] missing packages in the Pharo50 repository

2015-04-21 Thread Ben Coman

On Tue, Apr 21, 2015 at 5:49 PM, Esteban Lorenzano esteba...@gmail.com
wrote:


 On 21 Apr 2015, at 11:42, Ben Coman b...@openinworld.com wrote:

 btw, how do you merge Configurations?  For example, if I fix something X
 in my image and continue to work in it a month while the Image
 Configurations move forward, how do avoid losing that fix when I update to
 the latest Configuration ?


 you *do not* merge configurations.



I might have the wrong end of the stick, but I just want to push this idea
to the extreme for a moment, since I thought merging was the very essence
of collaborative development.  Git seems to have become popular in part
because it makes it very easy to *merge* parallel paths of development.
How do you avoid feature development interfering with fast bug fixing
without multiple paths of development (i.e. multiple Configurations) and
hence without making it easy to merge Configurations.

Suppose a developer outside the core group submits a feature/bug-fix across
five packages of the project's Configuration.  Should those packages just
be dropped into the project's repository? How do you tag them as
belonging-together, to simplify review by the project's owner - especially
if some of those packages are in different repositories.  I expect it would
be simpler if the outside-developer dropped a Configuration for the
feature/bug-fix, and the project owner could *merge* it into their image to
view all changes in one step.

cheers -ben



 if you fix  something in a “configured” project, you submit your change to
 proper repository (not as a SLICE, as regular packages), which in time will
 be included (or not, if “project owner” rejects it) in a new configuration
 that will be included in Pharo.

 that’s how any complex project works… and that’s how we should work too.
 SLICES are just a patch that exists because our system still not modular
 enough.


 Actually I guess it would be useful if a Configuration could be merged
 with the same GUI that merges a Slice.


 well… monkey and integrator app (integrators use it) does the proper
 loading.
 But I insist: configurations are not merged: versions are loaded, instead.

 cheers.
 Esteban

[Pharo-dev] Improving the documentation model

2015-04-21 Thread stephan


TL;DR: Some roadmap ideas. Looks like a lot of work.
Comments and improvements welcome:
We should replace the Pillar document format
by a better one, suitable for WYSIWYG editing and
creating long documents.

---

The current documentation model for Pharo is Pillar.
Pillar is the document model from the Pier CMS and
provides exports to (a.o) html and LaTeX. It is a
simplified form of the LaTeX document model
without a WYSIWYG UI.

In the research world two documentation systems
dominate: LaTeX and Word. Word and its clones
dominate areas where ease of use for small papers
without maths are important, LaTeX the other fields.

From personal experience I know that the lack of
abstraction in Word and clones makes it very expensive
to create large, consistently formatted documents.
In addition, the typographical quality of the resulting
documents is much lower than that achievable with
LaTeX.

On the other hand, repurposing LaTeX to generate
anything other than PDF/paper documentation is
difficult because of the underlying language that
LaTeX is written in, and there is no easy to use
WYSIWYG UI for LaTeX.

It pains me to see the return of text based formatting
with primitive formats like markdown. At least in LaTeX
you can preserve semantics level content, in markdown
we are back at html 1.0.

The program I liked best for creating longer documents
was Framemaker. That provided the needed abstractions
in an efficient WYSIWYG UI. Framemaker was sold
from 1986, so the performance of current hardware
should be enough to run something similar in smalltalk.
I used versions 5.5 and 6, and had to abandon it when
Adobe stopped development and it was never migrated
from PowerPC.

Framemaker was fast enough to create books with
hundreds and even thousands of pages. It had working
versions of the long document features Word claimed to
have.

With Athens and TxText we now have low level
abstractions for dealing with cursor and selection,  fonts,
rendering glyphs and having both on-screen and
PDF output.

On top of TxText we could add a model somewhat like
the attached figure
UML diagram of document structure
A book consists of a number of named documents.
This is essential for dealing with longer material, as
in a wysiwyg system we want to avoid having to re-layout
too much after a key is pressed. Across documents we only
need to remember the starting page/section numbers.

Each document consists of pages. On a page there can be fixed
content and content that is dependent on the text flow.
Most pages of a document have a similar layout, so each page
refers to a masterpage that defines the default content.
A document can have separate masterpages for
first, left and right pages, and rotated or extra large ones.
A masterpage can define fixed items and calculated ones
(pagenumbers and current chapter). A textframedefinition
describes the textframes and the textflow for each textframe.

The text (and other in-line contents) of the document are stored
in paragraphs, which are stored in textflows.
The paragraphstyle of a paragraph knows how to layout it in
a textframe, and how to deal with the end of a textframe.
The paragraphstyle knows how to paginate, how to number
or provide other autotext at the beginning of a paragraph and
if the paragraph text should be part of a table of contents.
A textframe is  a (rectangular) area on a page.
The characterstyle of a paragraph is responsible for the font family,
size and style. The characterstyle can be overridden
by a specific paragraph or by a textrange.

With a model like this (and adding maths, tables, notes, figures
and references) we should be able to use Pharo to create both
high-quality documentation, and write research articles
(and books) in-image.

 Stephan

Re: [Pharo-dev] missing packages in the Pharo50 repository

2015-04-21 14:53 GMT+02:00 Esteban Lorenzano esteba...@gmail.com:


  On 21 Apr 2015, at 14:37, Stephan Eggermont step...@stack.nl wrote:
 
  On 21/04/15 13:14, Esteban Lorenzano wrote:
 
  nope, solution is to explicit version to load :)
 
  Explicit symbolic version, that is.
  Never a fixed number, as that can't be patched.
  That breaks the update process just as well.

 no... explicit fixed number. I need version 1.0.42, not #stable or
 #myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42
 And of course can be patched with version 1.0.43.


Where are those version numbers stored?

Is it possible to modify a configuration outside and break that process?

That's the only way to be able to make the update process work.


No.

Thierry



 Esteban

 
  Stephan

Re: [Pharo-dev] missing packages in the Pharo50 repository




Le 21/4/15 12:49, Esteban Lorenzano a écrit :


On 21 Apr 2015, at 11:42, Ben Coman b...@openinworld.com 
mailto:b...@openinworld.com wrote:


btw, how do you merge Configurations?  For example, if I fix 
something X in my image and continue to work in it a month while 
the Image Configurations move forward, how do avoid losing that fix 
when I update to the latest Configuration ?


you *do not* merge configurations.
if you fix  something in a “configured” project, you submit your 
change to proper repository (not as a SLICE, as regular packages), 
which in time will be included (or not, if “project owner” rejects it) 
in a new configutation that will be included in Pharo.


that’s how any complex project works… and that’s how we should work 
too. SLICES are just a patch that exists because our system still not 
modular enough.


Well in reality you will still use slice because reality is more complex 
than our dreams. But you are right at the conceptual point of view :)




Actually I guess it would be useful if a Configuration could be 
merged with the same GUI that merges a Slice.


well… monkey and integrator app (integrators use it) does the proper 
loading.
But I insist: configurations are not merged: versions are loaded, 
instead.


cheers.
Esteban



cheers -ben

On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano 
esteba...@gmail.com mailto:esteba...@gmail.com wrote:



 On 21 Apr 2015, at 08:06, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:

 It means that we should also add the repositories of these
projects so that MC can merge no?
well, but you should not merge this projects :)


 Le 20/4/15 22:19, Esteban Lorenzano a écrit :
 they are handled separately, through configurations.

 cheers,
 Esteban

 On 20 Apr 2015, at 21:02, Pavel Krivanek
pavel.kriva...@gmail.com mailto:pavel.kriva...@gmail.com wrote:

 Hi,

 these packages do not have a version in the Pharo50 repository:

 Athens-Balloon
 Athens-Cairo
 Athens-CairoPools
 Athens-Core
 Athens-Examples
 Athens-Morphic
 Athens-Text
 ConfigurationOfAthens
 ConfigurationOfGlamourCore
 ConfigurationOfGTInspectorCore
 ConfigurationOfGToolkitCore
 ConfigurationOfGTPlaygroundCore
 ConfigurationOfGTSpotter
 ConfigurationOfOSWindow
 ConfigurationOfRubric
 ConfigurationOfShoreLineReporter
 ConfigurationOfTxText
 ConfigurationOfVersionner
 ConfigurationOfZincHTTPComponents
 Glamour-Announcements
 Glamour-Browsers
 Glamour-Core
 Glamour-Examples
 Glamour-Helpers
 Glamour-Morphic-Brick
 Glamour-Morphic-Brick-Tests
 Glamour-Morphic-Pager
 Glamour-Morphic-Renderer
 Glamour-Morphic-Theme
 Glamour-Morphic-Widgets
 Glamour-Presentations
 Glamour-Rubric-Presentations
 Glamour-Tests-Core
 Glamour-Tests-Morphic
 Glamour-Tests-Resources
 Glamour-Tests-Rubric
 GT-Inspector
 GT-InspectorExtensions-Core
 GT-Playground
 GT-Spotter
 GT-Spotter-EventRecorder
 GT-SpotterExtensions-Core
 GT-Tests-Inspector
 GT-Tests-Playground
 GT-Tests-Spotter
 OSWindow-SDL2
 OSWindow-VM
 Rubric
 ShoreLine-Report-Core
 ShoreLine-Report-Settings
 ShoreLine-Report-UI
 TxText-AthensTests
 TxText-Model
 TxText-Styler
 TxTextTests-Model
 Versionner-Core-Commands
 Versionner-Core-Model
 Versionner-Spec-Browser
 Versionner-Tests-Core-Model
 Zinc-HTTP
 Zinc-Character-Encoding-Core
 Zinc-Character-Encoding-Tests
 Zinc-Resource-Meta-Core
 Zinc-Resource-Meta-Tests
 Zinc-Tests
 Zinc-Zodiac
 Zodiac-Core
 Zodiac-Tests

 Cheers,
 -- Pavel

Re: [Pharo-dev] missing packages in the Pharo50 repository


On 21/04/15 14:53, Esteban Lorenzano wrote:



On 21 Apr 2015, at 14:37, Stephan Eggermont step...@stack.nl wrote:

On 21/04/15 13:14, Esteban Lorenzano wrote:


nope, solution is to explicit version to load :)


Explicit symbolic version, that is.
Never a fixed number, as that can't be patched.
That breaks the update process just as well.


no… explicit fixed number. I need version 1.0.42, not #stable or 
#myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42
And of course can be patched…. with version 1.0.43.
That’s the only way to be able to make the update process work.


The explicit version number is something you record while loading and
put in a snapshot class/log. Please think through how this is supposed 
to work, for all stakeholders involved.


Stephan

Re: [Pharo-dev] missing packages in the Pharo50 repository


@esteban Pavel is not stupid. So we could ask him what are his scenarios.

@Pavel So pavel can you explain what and why you need?

And yes we will have to have another level of tooling because
now it can be really difficult

@esteban
we should add the repositories to the projects because we should be able 
to publish
in this repositories. Else it will be again the time of the guy fixing a 
problem that will be consumed.


Or we can also simply say to people that we do not care of their time, 
but I would prefer that we pay attention.
In that case this is simple for me I will not fix or even look at code 
that is not in the

main system and with this approach we will all have lost something.


Stef

Re: [Pharo-dev] TDD and BDD


Le 21 avr. 2015 à 13:44, Sean P. DeNigris a écrit :

 Miguel Moquillon wrote
 BDD and TDD stands for different purposes with different actors...
 
 While that's unfortunately often true in practice, there is no difference
 philosophically. [T|B]DD done right always focuses on the user. But
 because of the word test in TDD, many tests (including many in our image)
 became incomprehensible from a how do I use this library POV, tested
 internal implementation details, etc. So BDD was invented to make the focus
 on behaviors explicit and to guide us all toward best practice. It also
 quite nicely unified acceptance testing and unit testing.
 
 The In order to... that you're describing is the outer, high-level
 acceptance test that in Ruby for example might be written with Cucumber. But
 once one has a failing acceptance test, the next step in BDD is to drop down
 into e.g. RSpec and write something a lot closer to a unit test, often
 mocking out collaborators to drive creation of an API.

this one is often called the outside - in loop (ref: 
http://dannorth.net/whats-in-a-story/).
Even is the outside - in loop is not used, I find valuable to encourage people 
to name (and write) their unit tests in terms of behavior.


smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Phaor 50: updating Metacello




Stef,

While in development you should be doing builds with the most recent 
version on the github master branch ... that way if you hit problems 
and Christophe or I have bugfixes along the way, 


yes

those fixes will be folded into the latest build ... I will add 
Pharo5.0 to my travis testing lineup shortly ...

Re: [Pharo-dev] New Download instructions (esp. for GNU/Linux)


Superb!
Thanks for making Pharo experience much better.

Stef

Le 20/4/15 21:23, Sean P. DeNigris a écrit :

We revamped the download instructions to incorporate the new VM builds and
platform all-in-ones. The biggest improvement was that GNU/Linux now has its
own instruction page laying out the various options and gotchas. Of course
we should continue to improve, but IMHO we have addressed the most
persistent gotchas.

Check out the pages: http://pharo.org/download and
http://pharo.org/gnu-linux-installation (which is linked from the first)

Next up: we'd like to use the OpenBuildService to build from sources for all
supported GNU/Linux configurations. Help is welcome!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/New-Download-instructions-esp-for-GNU-Linux-tp4820692.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Recommended image resolution for Pillar books?

2015-04-21 Thread Damien Cassou


Dmitri Zagidulin dmi...@zagidulin.net writes:

 2. Does it matter (is it advantageous) whether one puts the width=
 attribute on the figure declarations?


I would use the width attribute to size the image with respect to his
surrounding text (e.g., half of the line width).

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another without
losing enthusiasm. --Winston Churchill

Re: [Pharo-dev] TDD and BDD

Hi,

Le 21 avr. 2015 à 10:14, Miguel Moquillon a écrit :

 Hi,
 
 BDD and TDD stands for different purposes with different actors.
 In BDD, stakeholders work on the functionalities of software units (coarse 
 grain, black-box approach) whereas on TDD developers work on the object's 
 features (fine-grain, white-box approach) that made the functionalities. So, 
 the tooling in BDD should be different of the tooling used in TDD (BDD is 
 more high-level than TDD).
 
 In BDD each functionalities are describes as :
 
 As a role
 I want some feature
 So that I gain a benefit
 
 And the functionality is described in different scenarios (nominal and error 
 ones) :
 Given some initial context
 When an event occurs
 Then ensure some outcomes
 
 Basic example:
 
 As a customer,
 I want to withdraw cash from an ATM,
 so that I don’t have to wait in line at the bank.
 
 Scenario 1: Account is in credit
 Given the account is in credit
 And the card is valid
 And the dispenser contains cash
 When the customer requests cash
 Then ensure the account is debited
 And ensure cash is dispensed
 And ensure the card is returned
 
 In fact, a useful and good BDD tool must provide :
 a way to define a set of initial data
 a DSL to define the functionalities and for each of them to express the 
 scenarios according to the schema above
 an engine that feeds automatically the scenario from the data set and that 
 outputs the result.
 Miguel Moquillon

yes, you're right on all these points. I'm not aware of such a library for 
Pharo but it would be very nice. On top of that, you could add a dashboard 
collecting automatically these tests (that are more or less User Stories) to 
show your customer which user stories are completed.

To come back to my proposition, it is just a first step to BDD to not prevent 
people to define tests with something like 
shouldAccountBalanceBePositiveAfterEachOperation (more behavior driven) rather 
than testMyWonderfulMethod that may leads people to test the implementation 
details and not the expected behavior.



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Little fix to MC merge facility

2015-04-21 Thread Jan Vrany

On Tue, 2015-04-21 at 08:41 +0200, Thierry Goubier wrote:
 Le 21/04/2015 07:46, stepharo a écrit :
 
  No, I changed MCMethodDefinition= to be more relaxed about
  sources and treat two sources that differ only in leading/trailing
  spaces as same. This way, these methods do not occur in merge tool
  at all.
  This is just a quick fix - much better would be to compare AST's and
  treat whitespace-changes specially (i.e., provide a filter to show/hide
  whitespace-only-changes).
 
  OK now I wonder if we want to have methods with different end of line
  conventions in the system.
 
 I pushed a change to MCMethodDefinition#= a short while ago because 
 source code was seeing line ending changes...

Could you point me to that? If you don't mind, I'll merge it as it could
help to solve problems I might soon run into :-) 

 
 AST-based comparison would be nice there; however what about the cost? 
 Some of MC operations are already fairly slow as they are now.

If done on a tool level (where this belongs to IMO) it won't be much of
a problem. Only one might have to wait for window to come up a 
little longer...

 
 Thierry
 
  I do not remember the discussion we got long time ago.
 
  Stef
  Do you think that we should integrate it?
  Yes.
 
  Stef
 
  Le 20/4/15 12:36, Jan Vrany a écrit :
  Hi,
 
  I just wanted to merge some code in Monticello and the merge tool
  marked all methods as conflict because their source differ in trailing
  whitespace (newline). The diff panel on the right does not show any
  difference.
 
  http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVrany.1
 
 
  Here's a fix for this particular problem in case somebody runs into the
  same problem.
 
  Best, Jan

Re: [Pharo-dev] TDD and BDD


On 21/04/15 10:14, Miguel Moquillon wrote:

In BDD each functionalities are describes as :

As a role
I want some feature
So that I gain a benefit

And the functionality is described in different scenarios (nominal and
error ones) :
Given some initial context
When an event occurs
Then ensure some outcomes


This can be mapped rather easily on a subclass of TestCase, even the
variants with tabled examples. With glamour now in the core, it is
easy to make a specialized browser (and editor) for these tests.
Given and When map to setUp, then to the test. Just add BDDGoal
BDDStakeHolder and BDDFeature and make sure that a BDDTest refers to
them.

Stephan

Re: [Pharo-dev] missing packages in the Pharo50 repository


 On 21 Apr 2015, at 11:42, Ben Coman b...@openinworld.com wrote:
 
 btw, how do you merge Configurations?  For example, if I fix something X in 
 my image and continue to work in it a month while the Image Configurations 
 move forward, how do avoid losing that fix when I update to the latest 
 Configuration ?

you *do not* merge configurations. 
if you fix  something in a “configured” project, you submit your change to 
proper repository (not as a SLICE, as regular packages), which in time will be 
included (or not, if “project owner” rejects it) in a new configutation that 
will be included in Pharo. 

that’s how any complex project works… and that’s how we should work too. SLICES 
are just a patch that exists because our system still not modular enough. 

 
 Actually I guess it would be useful if a Configuration could be merged with 
 the same GUI that merges a Slice.

well… monkey and integrator app (integrators use it) does the proper loading. 
But I insist: configurations are not merged: versions are loaded, instead. 

cheers. 
Esteban

 
 cheers -ben
 
 On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano esteba...@gmail.com 
 mailto:esteba...@gmail.com wrote:
 
  On 21 Apr 2015, at 08:06, stepharo steph...@free.fr 
  mailto:steph...@free.fr wrote:
 
  It means that we should also add the repositories of these projects so that 
  MC can merge no?
 well, but you should not merge this projects :)
 
 
  Le 20/4/15 22:19, Esteban Lorenzano a écrit :
  they are handled separately, through configurations.
 
  cheers,
  Esteban
 
  On 20 Apr 2015, at 21:02, Pavel Krivanek pavel.kriva...@gmail.com 
  mailto:pavel.kriva...@gmail.com wrote:
 
  Hi,
 
  these packages do not have a version in the Pharo50 repository:
 
  Athens-Balloon
  Athens-Cairo
  Athens-CairoPools
  Athens-Core
  Athens-Examples
  Athens-Morphic
  Athens-Text
  ConfigurationOfAthens
  ConfigurationOfGlamourCore
  ConfigurationOfGTInspectorCore
  ConfigurationOfGToolkitCore
  ConfigurationOfGTPlaygroundCore
  ConfigurationOfGTSpotter
  ConfigurationOfOSWindow
  ConfigurationOfRubric
  ConfigurationOfShoreLineReporter
  ConfigurationOfTxText
  ConfigurationOfVersionner
  ConfigurationOfZincHTTPComponents
  Glamour-Announcements
  Glamour-Browsers
  Glamour-Core
  Glamour-Examples
  Glamour-Helpers
  Glamour-Morphic-Brick
  Glamour-Morphic-Brick-Tests
  Glamour-Morphic-Pager
  Glamour-Morphic-Renderer
  Glamour-Morphic-Theme
  Glamour-Morphic-Widgets
  Glamour-Presentations
  Glamour-Rubric-Presentations
  Glamour-Tests-Core
  Glamour-Tests-Morphic
  Glamour-Tests-Resources
  Glamour-Tests-Rubric
  GT-Inspector
  GT-InspectorExtensions-Core
  GT-Playground
  GT-Spotter
  GT-Spotter-EventRecorder
  GT-SpotterExtensions-Core
  GT-Tests-Inspector
  GT-Tests-Playground
  GT-Tests-Spotter
  OSWindow-SDL2
  OSWindow-VM
  Rubric
  ShoreLine-Report-Core
  ShoreLine-Report-Settings
  ShoreLine-Report-UI
  TxText-AthensTests
  TxText-Model
  TxText-Styler
  TxTextTests-Model
  Versionner-Core-Commands
  Versionner-Core-Model
  Versionner-Spec-Browser
  Versionner-Tests-Core-Model
  Zinc-HTTP
  Zinc-Character-Encoding-Core
  Zinc-Character-Encoding-Tests
  Zinc-Resource-Meta-Core
  Zinc-Resource-Meta-Tests
  Zinc-Tests
  Zinc-Zodiac
  Zodiac-Core
  Zodiac-Tests
 
  Cheers,
  -- Pavel

Re: [Pharo-dev] TDD and BDD


Le 21 avr. 2015 à 10:44, Sven Van Caekenberghe a écrit :

 
 On 21 Apr 2015, at 10:36, Christophe Demarey christophe.dema...@inria.fr 
 wrote:
 
 To come back to my proposition, it is just a first step to BDD to not 
 prevent people to define tests with something like 
 shouldAccountBalanceBePositiveAfterEachOperation (more behavior driven) 
 rather than testMyWonderfulMethod that may leads people to test the 
 implementation details and not the expected behavior.
 
 Not that your naming ideas are bad, but right now you can write
 
 testAccountShouldBePositiveAfterEachOperation
 
 which is not that bad

I agree. I do not want to push things that won't be used. That's why I did not 
yet proposed a slice.
Maybe I will just let it as it is now and just propose to include the 
refactoring to have the logic of the test selection in one place.
With Guille, we discussed a bit around tests and came to the conclusion that it 
would be good to have a blog post or a book chapter on test solutions and how 
to test the good thing.
We have, for example:
SUnit
BabyMock (http://smalltalkhub.com/#!/~zeroflag/BabyMock2)
Mocketry (http://smalltalkhub.com/#!/~dionisiy/Mocketry)
PhExample (http://smalltalkhub.com/#!/~PharoExtras/Phexample)
BoTest (http://smalltalkhub.com/#!/~CAR/BoTest)
Kiwi TDD (https://www.youtube.com/watch?v=m2t_MbVAdis)
and maybe others.

Thanks for the feedback.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] TDD and BDD

On 21 Apr 2015, at 10:22, Christophe Demarey christophe.dema...@inria.fr
wrote:

Le 20 avr. 2015 à 18:23, Sean P. DeNigris a écrit :

Sean P. DeNigris wrote
refactor so that all those places use one implementation somewhere.

In fact, searching the sources for beginsWith: 'test', the logic is
duplicated quite a bit. And someone even snuck your proposed change into
CompiledMethod#isTestMethod, so now we already have two conflicting
concepts of what a test selector is in Core.

In fact, I already did the changes in an image (but not published, I wait for
feedback) and I also noticed the duplicated logic.
Monty also pointed me to take care of this problem:
https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-tests-and-tries-to-run-them-TestRunner-doesn-t

https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-tests-and-tries-to-run-them-TestRunner-doesn-t.

What I did is really simple:
In TestCase Class,
add
Capture d’écran 2015-04-21 à 10.12.36.png

hi, side note:
take into account that the use of #or: as you are using it is not recommended.
Better something like:

firstTerm
or: [ secondTerm
or: [ thirdTerm
or [ etc. ] ] ]

yes, is uglier, but faster :)

cheers,
Esteban

update #testSelectors and #methodChanged: to use #isTestSelector:
update shouldInheritSelectors to fix a wrong behavior
In ClassTestCase, update selectorsTested to use #isTestSelector:
Update Nautilus extension method CompiledMethodisTestMethod to use
TestCase#isTestSelector:

I will add a slice for that but I'm not sure if it is a good idea to include
tests beginning with deny.

Re: [Pharo-dev] Little fix to MC merge facility

2015-04-21 10:45 GMT+02:00 Jan Vrany jan.vr...@fit.cvut.cz:

 On Tue, 2015-04-21 at 08:41 +0200, Thierry Goubier wrote:
  Le 21/04/2015 07:46, stepharo a écrit :
  
   No, I changed MCMethodDefinition= to be more relaxed about
   sources and treat two sources that differ only in leading/trailing
   spaces as same. This way, these methods do not occur in merge tool
   at all.
   This is just a quick fix - much better would be to compare AST's and
   treat whitespace-changes specially (i.e., provide a filter to
 show/hide
   whitespace-only-changes).
  
   OK now I wonder if we want to have methods with different end of line
   conventions in the system.
 
  I pushed a change to MCMethodDefinition#= a short while ago because
  source code was seeing line ending changes...

 Could you point me to that? If you don't mind, I'll merge it as it could
 help to solve problems I might soon run into :-)


Well, this is just the line in the = which says:

 aDefinition source withSqueakLineEndings = self source
withSqueakLineEndings



 
  AST-based comparison would be nice there; however what about the cost?
  Some of MC operations are already fairly slow as they are now.

 If done on a tool level (where this belongs to IMO) it won't be much of
 a problem. Only one might have to wait for window to come up a
 little longer...


The problem is that this = is used whenever you want to load a method
definition or to determine what are the changes you want to save.

Repeat by the number of methods and you start to see an effect ;) Try
loading Roassal for an example of what I mean...

In the other hand, as long as we're using the RBParser to get an AST,
parsing is fast.

Thierry


 
  Thierry
 
   I do not remember the discussion we got long time ago.
  
   Stef
   Do you think that we should integrate it?
   Yes.
  
   Stef
  
   Le 20/4/15 12:36, Jan Vrany a écrit :
   Hi,
  
   I just wanted to merge some code in Monticello and the merge tool
   marked all methods as conflict because their source differ in
 trailing
   whitespace (newline). The diff panel on the right does not show any
   difference.
  
  
 http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVrany.1
  
  
   Here's a fix for this particular problem in case somebody runs into
 the
   same problem.
  
   Best, Jan

Re: [Pharo-dev] TDD and BDD


Le 21 avr. 2015 à 11:38, Esteban Lorenzano a écrit :

 
 On 21 Apr 2015, at 10:22, Christophe Demarey christophe.dema...@inria.fr 
 wrote:
 
 
 Le 20 avr. 2015 à 18:23, Sean P. DeNigris a écrit :
 
 Sean P. DeNigris wrote
 refactor so that all those places use one implementation somewhere.
 
 In fact, searching the sources for beginsWith: 'test', the logic is
 duplicated quite a bit. And someone even snuck your proposed change into
 CompiledMethod#isTestMethod, so now we already have two conflicting
 concepts of what a test selector is in Core.
 
 In fact, I already did the changes in an image (but not published, I wait 
 for feedback) and I also noticed the duplicated logic.
 Monty also pointed me to take care of this problem: 
 https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-tests-and-tries-to-run-them-TestRunner-doesn-t.
 
 What I did is really simple:
 In TestCase Class,
 add 
 Capture d’écran 2015-04-21 à 10.12.36.png
 
 hi, side note: 
 take into account that the use of #or: as you are using it is not 
 recommended. 
 Better something like: 
 
 firstTerm 
   or: [ secondTerm 
   or: [ thirdTerm 
   or [ etc. ] ] ]
 
 yes, is uglier, but faster :)


ok ;)

smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] verveinJ cannot create mse with too big input

2015-04-21 Thread Fabrizio Perin

Hello,
I was trying to create an MSE file with VerveinJ and I got an incomplete
MSE at the following error on the console:

*Exception while Visiting famix repository entities. For example, this
might happen when an entity inside the repository has a property refering
to an entity outside the repository*
*  Entity ID: 69580 (a FAMIX.AnnotationInstanceAttribute), property:
parentAnnotationInstance*
*Exception in thread main java.lang.NoClassDefFoundError:
fr/inria/verveine/core/gen/famix/NamedEntity*
*at
ch.akuhn.fame.internal.RepositoryVisitor.acceptElement(RepositoryVisitor.java:111)*
*at
ch.akuhn.fame.internal.RepositoryVisitor.acceptVisitor(RepositoryVisitor.java:162)*
*at
ch.akuhn.fame.internal.RepositoryVisitor.run(RepositoryVisitor.java:207)*
*at ch.akuhn.fame.Repository.accept(Repository.java:105)*
*at ch.akuhn.fame.Repository.exportMSE(Repository.java:216)*
*at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown
Source)*
*at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown
Source)*
*at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown
Source)*
*at
eu.synectique.verveine.extractor.java.VerveineJParser.main(Unknown Source)*
*Caused by: java.lang.ClassNotFoundException:
fr.inria.verveine.core.gen.famix.NamedEntity*
*at java.net.URLClassLoader$1.run(URLClassLoader.java:366)*
*at java.net.URLClassLoader$1.run(URLClassLoader.java:355)*
*at java.security.AccessController.doPrivileged(Native Method)*
*at java.net.URLClassLoader.findClass(URLClassLoader.java:354)*
*at java.lang.ClassLoader.loadClass(ClassLoader.java:423)*
*at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)*
*at java.lang.ClassLoader.loadClass(ClassLoader.java:356)*
*... 9 more *


I'm using windows, not sure how to get the version of verveinJ. The same
does not happen if I split the project in two parts and I parse them
separately.

Is it known error or am I doing something wrong?

Thanks in advance,
Fabrizio

Re: [Pharo-dev] missing packages in the Pharo50 repository

2015-04-21 Thread Ben Coman

btw, how do you merge Configurations?  For example, if I fix something X
in my image and continue to work in it a month while the Image
Configurations move forward, how do avoid losing that fix when I update to
the latest Configuration ?

Actually I guess it would be useful if a Configuration could be merged with
the same GUI that merges a Slice.

cheers -ben

On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano esteba...@gmail.com
wrote:


  On 21 Apr 2015, at 08:06, stepharo steph...@free.fr wrote:
 
  It means that we should also add the repositories of these projects so
 that MC can merge no?
 well, but you should not merge this projects :)

 
  Le 20/4/15 22:19, Esteban Lorenzano a écrit :
  they are handled separately, through configurations.
 
  cheers,
  Esteban
 
  On 20 Apr 2015, at 21:02, Pavel Krivanek pavel.kriva...@gmail.com
 wrote:
 
  Hi,
 
  these packages do not have a version in the Pharo50 repository:
 
  Athens-Balloon
  Athens-Cairo
  Athens-CairoPools
  Athens-Core
  Athens-Examples
  Athens-Morphic
  Athens-Text
  ConfigurationOfAthens
  ConfigurationOfGlamourCore
  ConfigurationOfGTInspectorCore
  ConfigurationOfGToolkitCore
  ConfigurationOfGTPlaygroundCore
  ConfigurationOfGTSpotter
  ConfigurationOfOSWindow
  ConfigurationOfRubric
  ConfigurationOfShoreLineReporter
  ConfigurationOfTxText
  ConfigurationOfVersionner
  ConfigurationOfZincHTTPComponents
  Glamour-Announcements
  Glamour-Browsers
  Glamour-Core
  Glamour-Examples
  Glamour-Helpers
  Glamour-Morphic-Brick
  Glamour-Morphic-Brick-Tests
  Glamour-Morphic-Pager
  Glamour-Morphic-Renderer
  Glamour-Morphic-Theme
  Glamour-Morphic-Widgets
  Glamour-Presentations
  Glamour-Rubric-Presentations
  Glamour-Tests-Core
  Glamour-Tests-Morphic
  Glamour-Tests-Resources
  Glamour-Tests-Rubric
  GT-Inspector
  GT-InspectorExtensions-Core
  GT-Playground
  GT-Spotter
  GT-Spotter-EventRecorder
  GT-SpotterExtensions-Core
  GT-Tests-Inspector
  GT-Tests-Playground
  GT-Tests-Spotter
  OSWindow-SDL2
  OSWindow-VM
  Rubric
  ShoreLine-Report-Core
  ShoreLine-Report-Settings
  ShoreLine-Report-UI
  TxText-AthensTests
  TxText-Model
  TxText-Styler
  TxTextTests-Model
  Versionner-Core-Commands
  Versionner-Core-Model
  Versionner-Spec-Browser
  Versionner-Tests-Core-Model
  Zinc-HTTP
  Zinc-Character-Encoding-Core
  Zinc-Character-Encoding-Tests
  Zinc-Resource-Meta-Core
  Zinc-Resource-Meta-Tests
  Zinc-Tests
  Zinc-Zodiac
  Zodiac-Core
  Zodiac-Tests
 
  Cheers,
  -- Pavel

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

Le 21 avr. 2015 à 16:32, Otto Behrens a écrit :

Thanks. I do altjc on a method sometimes when I have changed a
method. So sometimes I so altjm and then immediately altjc to
check all the tests in the class.

Indeed, Nautilus logic to run test differs a bit from the TestRunner logic.

Does it really have to be?

No, it should not.

For example, if your test fails, it is run a second time to open a debugger
but it could do side effects.

This has been a problem for me for a long time. I would *love* it if
Nautilus runs a single test in debug mode (and not a second time). It
is especially painful when running selenium tests in our environment,
because firefox is launched on every test suite run, which makes
running a single test relatively expensive. I suppose solving the
problem of tests running a long time is first prize.

Why don't you just run your tests from the test runner or using MyTestClass
run: #testSelector ?

Because I normally run the tests that I work on while I'm in the
Nautilus browser (using shortcut keys). Why would I want to launch a
different browser, search for the class I'm working on and run the
tests there?

It was a suggestion for your use case.
If you only want to run the test you are working on, Nautilus helps.

I could be missing it totally here. I'm quite interested to know how
other people work. A sort of work flow, to the point of running tests.

We miss a functionality in Pharo to easily run (a shorcut) a set of selected
tests (ex: your project tests). This way, you can have a quick feedback on your
updates.
As it is not so easy, I often fallback to run tests from Nautilus (a test class
or sometimes only a test method).

To run all my tests take a long time. There are quite a few.

We will need to clean this kind of logic that should not be part of
Nautilus. Could you open a bug entry for that?

https://pharo.fogbugz.com/f/cases/15374/exception-handling-when-running-tests-in-Nautilus

Yes.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

2015-04-21 Thread Nicolai Hess

2015-04-21 16:03 GMT+02:00 Christophe Demarey christophe.dema...@inria.fr:

 Indeed, Nautilus logic to run test differs a bit from the TestRunner logic.

 We will need to clean this kind of logic that should not be part of
 Nautilus.


Just for reference:

13024 https://pharo.fogbugz.com/default.asp?13024
Discrepancy between TestRunner and Nautilus test running for method
#shouldNotImplementMethod
14864 https://pharo.fogbugz.com/default.asp?14864
Nautillus do not launch the test cases on some classes
12851 https://pharo.fogbugz.com/default.asp?12851
Test is executed twice when failling








 Regards,
 Christophe.

 Le 21 avr. 2015 à 15:34, Otto Behrens a écrit :

  I realised I may have posted this on the wrong list. Is there anyone
  that can help with this one please?
 
 
  -- Forwarded message --
  From: Otto Behrens o...@finworks.biz
  Date: Sun, Apr 19, 2015 at 10:08 AM
  Subject: exception handling problem when running tests in Nautilus
  To: pharo-us...@lists.pharo.org
 
 
  Hi,
 
  Thanks everyone for the new Pharo and all the work done. I like Spotter!
 
  I gave Pharo 4 a try today and ran into a problem with running tests
  in a TestCase (test class - run tests). I just get the debugger
  popping up with WARequestContextNotFound.
 
  In the setUp of our test case, we call WACurrentRequestContext value,
  but handle the error when we do not have a context, for example:
 
  [ WACurrentRequestContext value. true ]
  on: WARequestContextNotFound
  do: [ :e | false ]
 
  This handler: [ :e | false ] is never called. What influences this
  is the exception handling in:
 
  AbstractNautilusUI  #runTestsOfClass:notifying:
 
  Firstly, I think that it may be slighly better to call e pass or e
  outer in stead of e defaultAction, as this would give another outer
  handler a chance to do something. The defaultAction is called when
  there are no more outer handlers anyway.
 
  After trying this, it did not help my cause. And I think that this is
  because the WACurrentRequestContext is a Notification and not an
  Error.
 
  I then replaced Exception with Error in the handler in
  AbstractNautilusUI. This seem to work. What also works is to
  completely remove the exception handling in AbstractNautilusUI 
  #runTestsOfClass:notifying:
 
  What is a bit strange is the inconsistency in this exception handling
  when running a suite or an individual test. Perhaps this kind of code
  could be better on the TestSuite and not in the Nautilus UI?
 
  Can anyone please help? Should I be doing something else?
 
  Cheers
  Otto

Re: [Pharo-dev] Roadmap




Le 20/4/15 20:47, Dmitri Zagidulin a écrit :

Sounds great. What is 'leading char'?


the fact that a string encodes its language.

Stef


On Mon, Apr 20, 2015 at 1:44 PM, stepharo steph...@free.fr 
mailto:steph...@free.fr wrote:




Similar question - are there any roadmap plans to add Dictionary
literals to Pharo?

We discussed about object format but right now I think that we
would like to (without thinking too much)
- take advantage of Athens
- continue to improve the tools
- put the bootstrap in production
- make SDL2 working for real and OSwindow
- clean spec
- FFI FFI FFI and again FFI
- continue the remodularisation effort

If I would open a new work place it would be
- to integrate Xtream and get rid of the old streams.
- clean/remove leading char

Stef



On Mon, Apr 20, 2015 at 1:20 PM, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:



Le 20/4/15 16:39, Dmitri Zagidulin a écrit :

I would love to see two things in Pharo 5:

1) Fix for mouse scrolling (at least on Mac OS X, though I
think it does the same on Linux etc) in the class pane.
While mouse-scrolling (either via a mouse wheel or
two-finger scrolling on the touchpad) through the classes,
the focus frequently and erratically jumps to the package
pane, and the package pane starts scrolling instead. The
focus also sometimes jumps when you reach the end of the
class list (and, again, the package pane starts scrolling
instead).


Yes



2) A button in the debugger that copies the error message to
the clipboard (you can sort of do it currently by editing
the title of the error window, but that's really awkward).


it should be easy to do.



I also have a question. Are there currently any roadmap
plans for namespaces or modules for Pharo? I saw a brief
discussion about it a few years back
(http://forum.world.st/Pharo-and-Namespaces-td4636635.html
), and wanted to see if it's still on the table.


Yes but not for Pharo 50.

Stef




On Mon, Apr 20, 2015 at 2:58 AM, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:

Hi

if you have suggestions please let us know. Now usually
suggestions often comes with time allocation ;)
We have definitively a list of points we want to see
addressed.

Stef

Le 19/4/15 23:19, Torsten Bergmann a écrit :

Do we have a roadmap for Pharo 5 already?

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30




Hi phil

just that you know what we are doing

 - Mathieu Lacatou an intern from Thales should be visiting the team for
10 days to pair program with esteban
 about the OSWindow multi-windowing support

 - JB and Merwan are extending the OSWindow touch support, like
generating scroll events

 - JB is working on Woden and adding some shadders for 3D demoes.

I will have a new guy from Senegal starting to work tomorrow in my lab
on using GPU and Wooden for doing SPHepidemiological modeling.
How to coordinate all these activities ?


Cool :)
I do not know
For now he should have a look at Woden, JB  planned to make a CI.
But he was blocked because of a bug in the old version of Metacello that 
we use.

So as soon as Metacello is updated, JB can continue his build.

Stef

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

2015-04-21 Thread Otto Behrens

Thanks. I do altjc on a method sometimes when I have changed a
method. So sometimes I so altjm and then immediately altjc to
check all the tests in the class.

 Indeed, Nautilus logic to run test differs a bit from the TestRunner logic.

Does it really have to be?

 For example, if your test fails, it is run a second time to open a debugger 
 but it could do side effects.

This has been a problem for me for a long time. I would *love* it if
Nautilus runs a single test in debug mode (and not a second time). It
is especially painful when running selenium tests in our environment,
because firefox is launched on every test suite run, which makes
running a single test relatively expensive. I suppose solving the
problem of tests running a long time is first prize.

 Why don't you just run your tests from the test runner or using MyTestClass 
 run: #testSelector ?

Because I normally run the tests that I work on while I'm in the
Nautilus browser (using shortcut keys). Why would I want to launch a
different browser, search for the class I'm working on and run the
tests there?

I could be missing it totally here. I'm quite interested to know how
other people work. A sort of work flow, to the point of running tests.

To run all my tests take a long time. There are quite a few.

 We will need to clean this kind of logic that should not be part of Nautilus. 
 Could you open a bug entry for that?

https://pharo.fogbugz.com/f/cases/15374/exception-handling-when-running-tests-in-Nautilus

Is this the right place?


 Regards,
 Christophe.

 Le 21 avr. 2015 à 15:34, Otto Behrens a écrit :

 I realised I may have posted this on the wrong list. Is there anyone
 that can help with this one please?


 -- Forwarded message --
 From: Otto Behrens o...@finworks.biz
 Date: Sun, Apr 19, 2015 at 10:08 AM
 Subject: exception handling problem when running tests in Nautilus
 To: pharo-us...@lists.pharo.org


 Hi,

 Thanks everyone for the new Pharo and all the work done. I like Spotter!

 I gave Pharo 4 a try today and ran into a problem with running tests
 in a TestCase (test class - run tests). I just get the debugger
 popping up with WARequestContextNotFound.

 In the setUp of our test case, we call WACurrentRequestContext value,
 but handle the error when we do not have a context, for example:

 [ WACurrentRequestContext value. true ]
 on: WARequestContextNotFound
 do: [ :e | false ]

 This handler: [ :e | false ] is never called. What influences this
 is the exception handling in:

 AbstractNautilusUI  #runTestsOfClass:notifying:

 Firstly, I think that it may be slighly better to call e pass or e
 outer in stead of e defaultAction, as this would give another outer
 handler a chance to do something. The defaultAction is called when
 there are no more outer handlers anyway.

 After trying this, it did not help my cause. And I think that this is
 because the WACurrentRequestContext is a Notification and not an
 Error.

 I then replaced Exception with Error in the handler in
 AbstractNautilusUI. This seem to work. What also works is to
 completely remove the exception handling in AbstractNautilusUI 
 #runTestsOfClass:notifying:

 What is a bit strange is the inconsistency in this exception handling
 when running a suite or an individual test. Perhaps this kind of code
 could be better on the TestSuite and not in the Nautilus UI?

 Can anyone please help? Should I be doing something else?

 Cheers
 Otto

[Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

2015-04-21 Thread Otto Behrens

I realised I may have posted this on the wrong list. Is there anyone
that can help with this one please?

-- Forwarded message --
From: Otto Behrens o...@finworks.biz
Date: Sun, Apr 19, 2015 at 10:08 AM
Subject: exception handling problem when running tests in Nautilus
To: pharo-us...@lists.pharo.org

Hi,

Thanks everyone for the new Pharo and all the work done. I like Spotter!

I gave Pharo 4 a try today and ran into a problem with running tests
in a TestCase (test class - run tests). I just get the debugger
popping up with WARequestContextNotFound.

In the setUp of our test case, we call WACurrentRequestContext value,
but handle the error when we do not have a context, for example:

[ WACurrentRequestContext value. true ]
on: WARequestContextNotFound
do: [ :e | false ]

This handler: [ :e | false ] is never called. What influences this
is the exception handling in:

AbstractNautilusUI  #runTestsOfClass:notifying:

Firstly, I think that it may be slighly better to call e pass or e
outer in stead of e defaultAction, as this would give another outer
handler a chance to do something. The defaultAction is called when
there are no more outer handlers anyway.

After trying this, it did not help my cause. And I think that this is
because the WACurrentRequestContext is a Notification and not an
Error.

I then replaced Exception with Error in the handler in
AbstractNautilusUI. This seem to work. What also works is to
completely remove the exception handling in AbstractNautilusUI 
#runTestsOfClass:notifying:

What is a bit strange is the inconsistency in this exception handling
when running a suite or an individual test. Perhaps this kind of code
could be better on the TestSuite and not in the Nautilus UI?

Can anyone please help? Should I be doing something else?

Cheers
Otto

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

Indeed, Nautilus logic to run test differs a bit from the TestRunner logic.
For example, if your test fails, it is run a second time to open a debugger but 
it could do side effects.

Why don't you just run your tests from the test runner or using MyTestClass 
run: #testSelector ?

We will need to clean this kind of logic that should not be part of Nautilus. 
Could you open a bug entry for that?

Regards,
Christophe.

Le 21 avr. 2015 à 15:34, Otto Behrens a écrit :

 I realised I may have posted this on the wrong list. Is there anyone
 that can help with this one please?
 
 
 -- Forwarded message --
 From: Otto Behrens o...@finworks.biz
 Date: Sun, Apr 19, 2015 at 10:08 AM
 Subject: exception handling problem when running tests in Nautilus
 To: pharo-us...@lists.pharo.org
 
 
 Hi,
 
 Thanks everyone for the new Pharo and all the work done. I like Spotter!
 
 I gave Pharo 4 a try today and ran into a problem with running tests
 in a TestCase (test class - run tests). I just get the debugger
 popping up with WARequestContextNotFound.
 
 In the setUp of our test case, we call WACurrentRequestContext value,
 but handle the error when we do not have a context, for example:
 
 [ WACurrentRequestContext value. true ]
 on: WARequestContextNotFound
 do: [ :e | false ]
 
 This handler: [ :e | false ] is never called. What influences this
 is the exception handling in:
 
 AbstractNautilusUI  #runTestsOfClass:notifying:
 
 Firstly, I think that it may be slighly better to call e pass or e
 outer in stead of e defaultAction, as this would give another outer
 handler a chance to do something. The defaultAction is called when
 there are no more outer handlers anyway.
 
 After trying this, it did not help my cause. And I think that this is
 because the WACurrentRequestContext is a Notification and not an
 Error.
 
 I then replaced Exception with Error in the handler in
 AbstractNautilusUI. This seem to work. What also works is to
 completely remove the exception handling in AbstractNautilusUI 
 #runTestsOfClass:notifying:
 
 What is a bit strange is the inconsistency in this exception handling
 when running a suite or an individual test. Perhaps this kind of code
 could be better on the TestSuite and not in the Nautilus UI?
 
 Can anyone please help? Should I be doing something else?
 
 Cheers
 Otto
 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] missing packages in the Pharo50 repository

Thierry Goubier wrote
 So, on a regular basis, you have a message which says: I tried to load the
 project X inside Pharo (where X, as an older version, is inside Pharo
 already) and it breaks here and there.

Isn't that what locking is for in the Metacello scripting API?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/missing-packages-in-the-Pharo50-repository-tp4820696p4820799.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] TDD and BDD

Miguel Moquillon wrote
 BDD and TDD stands for different purposes with different actors...

While that's unfortunately often true in practice, there is no difference
philosophically. [T|B]DD done right always focuses on the user. But
because of the word test in TDD, many tests (including many in our image)
became incomprehensible from a how do I use this library POV, tested
internal implementation details, etc. So BDD was invented to make the focus
on behaviors explicit and to guide us all toward best practice. It also
quite nicely unified acceptance testing and unit testing.

The In order to... that you're describing is the outer, high-level
acceptance test that in Ruby for example might be written with Cucumber. But
once one has a failing acceptance test, the next step in BDD is to drop down
into e.g. RSpec and write something a lot closer to a unit test, often
mocking out collaborators to drive creation of an API.

In summary, the intent of BDD is to be TDD Done Right. There is no
inherent conflict, and no specific tools are technically required. Although,
since as McLuhan suggested, we become our tools, so obviously the proper
tools may be decisive, especially when first learning.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/TDD-and-BDD-tp4820612p4820803.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] GNU/Linux Old libC CI Job

stepharo wrote
 We should probably put a link on the web site.

They are there :) http://pharo.org/download#custom



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/GNU-Linux-Old-libC-CI-Job-tp4820686p4820804.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] missing packages in the Pharo50 repository


On 21/04/15 13:14, Esteban Lorenzano wrote:


nope, solution is to explicit version to load :)


Explicit symbolic version, that is.
Never a fixed number, as that can't be patched.
That breaks the update process just as well.

Stephan

Re: [Pharo-dev] Recommended image resolution for Pillar books?

How would one do that? Does the width attribute take HTML style parameters
(px, %)?

On Tuesday, April 21, 2015, Damien Cassou damien.cas...@inria.fr wrote:


 Dmitri Zagidulin dmi...@zagidulin.net javascript:; writes:

  2. Does it matter (is it advantageous) whether one puts the width=
  attribute on the figure declarations?


 I would use the width attribute to size the image with respect to his
 surrounding text (e.g., half of the line width).

 --
 Damien Cassou
 http://damiencassou.seasidehosting.st

 Success is the ability to go from one failure to another without
 losing enthusiasm. --Winston Churchill

Re: [Pharo-dev] verveinJ cannot create mse with too big input

2015-04-21 Thread Fabrizio Perin

Thanks for the quick answer Nicolas, I tried to increase the Java memory in
the script but no better results. I will split the project in smaller
parts. Not a big deal in this case.

Thanks,
Fabrizio

2015-04-21 10:30 GMT+02:00 Nicolas Anquetil nicolas.anque...@inria.fr:


 it is a know fact, not an error :-)

 Basically, verveinej has to maintain several models of the project in
 memory to be able to do its job
 if the project is too big, this might end up exploding the memory and
 giving unexpected results

 That's why we implemented the incremental parsing option

 Now, what you are reporting looks like a bug, but because of the
 conditions, I am not sure it is really one, especially if it works fine
 when you split the project in 2

 You also have the option of twicking the calling script to increase java
 memory
 In the past, (sun) java used to require contiguous memory (just like
 pharo) but jikes removed this constraint
 I believe the new oracle java removed the constraint also, so you might be
 able to go pretty high in memory on a java execution ...

 Let us know if it works

 nicolas

 PS: This seems like a Moose-dev question rather than a pharo-dev one



 On 21/04/2015 10:21, Fabrizio Perin wrote:

 Hello,
 I was trying to create an MSE file with VerveinJ and I got an incomplete
 MSE at the following error on the console:

  *Exception while Visiting famix repository entities. For example, this
 might happen when an entity inside the repository has a property refering
 to an entity outside the repository*
 *  Entity ID: 69580 (a FAMIX.AnnotationInstanceAttribute), property:
 parentAnnotationInstance*
 *Exception in thread main java.lang.NoClassDefFoundError:
 fr/inria/verveine/core/gen/famix/NamedEntity*
 *at
 ch.akuhn.fame.internal.RepositoryVisitor.acceptElement(RepositoryVisitor.java:111)*
 *at
 ch.akuhn.fame.internal.RepositoryVisitor.acceptVisitor(RepositoryVisitor.java:162)*
 *at
 ch.akuhn.fame.internal.RepositoryVisitor.run(RepositoryVisitor.java:207)*
 *at ch.akuhn.fame.Repository.accept(Repository.java:105)*
 *at ch.akuhn.fame.Repository.exportMSE(Repository.java:216)*
 *at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown
 Source)*
 *at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown
 Source)*
 *at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown
 Source)*
 *at
 eu.synectique.verveine.extractor.java.VerveineJParser.main(Unknown Source)*
 *Caused by: java.lang.ClassNotFoundException:
 fr.inria.verveine.core.gen.famix.NamedEntity*
 *at java.net.URLClassLoader$1.run(URLClassLoader.java:366)*
 *at java.net.URLClassLoader$1.run(URLClassLoader.java:355)*
 *at java.security.AccessController.doPrivileged(Native Method)*
 *at java.net.URLClassLoader.findClass(URLClassLoader.java:354)*
 *at java.lang.ClassLoader.loadClass(ClassLoader.java:423)*
 *at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)*
 *at java.lang.ClassLoader.loadClass(ClassLoader.java:356)*
 *... 9 more *


  I'm using windows, not sure how to get the version of verveinJ. The same
 does not happen if I split the project in two parts and I parse them
 separately.

  Is it known error or am I doing something wrong?

  Thanks in advance,
 Fabrizio

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread Damien Cassou


stephan step...@stack.nl writes:

 TL;DR: Some roadmap ideas. Looks like a lot of work.
 Comments and improvements welcome:
 We should replace the Pillar document format
 by a better one, suitable for WYSIWYG editing and
 creating long documents.

I agree that Pillar is far from perfect. Do you propose to (1) start
something from scratch or to (2) improve Pillar? If you propose (1), how
much do you plan to spend each day and for how long before reaching
Pillar current's state? If you propose (2), you can start doing
something small today and finish the same day. With (2) you could
improve the current situation before we go to bed.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another without
losing enthusiasm. --Winston Churchill

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

2015-04-21 Thread Otto Behrens

 We miss a functionality in Pharo to easily run (a shorcut) a set of selected 
 tests (ex: your project tests). This way, you can have a quick feedback on 
 your updates.
 As it is not so easy, I often fallback to run tests from Nautilus (a test 
 class or sometimes only a test method).

This may be an idea: I once wrote a bit of Smalltalk code inspired by this:

http://www.junitmax.com/

We ran it in our dev environment for about 2 years, and took it out
when we upgraded to Pharo 3.0. I still miss it. Other members on the
project do not, generally.

When accepting a method, we ran some tests:
1. lint (on the method)
2. if the changed method is a test method, run it (debug)
3. if not, run at most 5 tests in the vicinity of the changed method
(look for some appropriate senders)

What we got for this:
1. TDD really beautiful. Accept a test method - debugger pops up -
write the code in the debugger - restart - rinse and repeat.
2. Lint complained instantly. Very useful. As and when.
3. Change domain code: breaking test pops up - edit code in the debugger!

Problems we had:
1. Monkey patching OmniBrowser to do stuff when accepting a method.
Work to figure out how in Nautilus :-(
2. Lint became slow. Lots of work to optimise and perhaps exclude some.
3. The responsiveness on accepting a method was just a slight bit slow
which put people off
4. Editing in the debugger and lists of methods: no refactoring, no
auto-formatting; pain

Solutions:
1. Make it run in the background (continuously). Protect from running too often.
2. Get the method list browser and debugger editors to behave the same
as Nautilus (at a method level)
3. Record information about failing tests, and run the ones that tend
to fail more often
4. Use changes to help with run tests for stuff that I am working on

[Pharo-dev] [pharo-project/pharo-core]

2015-04-21 Thread GitHub

  Branch: refs/tags/50003
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] de6e0a: 50003

2015-04-21 Thread GitHub

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
  
https://github.com/pharo-project/pharo-core/commit/de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e
  Author: Jenkins Build Server bo...@pharo-project.org
  Date:   2015-04-21 (Tue, 21 Apr 2015)

  Changed paths:
A AST-Core.package/NumberParser.class/class/testing/isNumber_.st
A AST-Tests-Core.package/NumberParserTest.class/instance/tests - 
Float/testIsNumber.st
R Deprecated40.package/NBWin32Caret.class/README.md
R Deprecated40.package/NBWin32Caret.class/class/accessing/getBlinkTime.st
R Deprecated40.package/NBWin32Caret.class/definition.st
R Deprecated40.package/NBWin32Menu.class/README.md
R Deprecated40.package/NBWin32Menu.class/definition.st
R Deprecated40.package/NBWin32MessageBox.class/README.md
R Deprecated40.package/NBWin32MessageBox.class/class/instance 
creation/messageBox_text_title_flags_.st
R Deprecated40.package/NBWin32MessageBox.class/class/instance 
creation/test.st
R Deprecated40.package/NBWin32MessageBox.class/definition.st
R Deprecated40.package/NBWin32Process.class/README.md
R 
Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcess.st
R 
Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st
R Deprecated40.package/NBWin32Process.class/definition.st
R 
Deprecated40.package/NBWin32Process.class/instance/accessing/getPriorityClass.st
R 
Deprecated40.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st
R 
Deprecated40.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st
R 
Deprecated40.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st
R 
Deprecated40.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st
R Deprecated40.package/NBWin32ShellTest.class/README.md
R Deprecated40.package/NBWin32ShellTest.class/definition.st
R 
Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st
R 
Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st
R 
Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st
R 
Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st
R 
Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st
R Deprecated40.package/NBWin32Thread.class/README.md
R 
Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThread.st
R 
Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st
R Deprecated40.package/NBWin32Thread.class/definition.st
R 
Deprecated40.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st
R Deprecated40.package/Password.class/README.md
R Deprecated40.package/Password.class/definition.st
R Deprecated40.package/ShadowLabelMorph.class/README.md
R Deprecated40.package/ShadowLabelMorph.class/definition.st
R Deprecated40.package/ShadowLabelMorph.class/instance/drawing/drawOn_.st
R Deprecated40.package/StartupLoader.class/README.md
R Deprecated40.package/StartupLoader.class/class/accessing/default.st
R Deprecated40.package/StartupLoader.class/definition.st
R Deprecated40.package/TimeStamp.class/README.md
R Deprecated40.package/TimeStamp.class/class/instance creation/now.st
R Deprecated40.package/TimeStamp.class/class/instance creation/readFrom_.st
R Deprecated40.package/TimeStamp.class/definition.st
R Deprecated40.package/TimeStamp.class/instance/printing/printOn_.st
R Deprecated40.package/TimeStamp.class/instance/squeak 
protocol/asTimeStamp.st
R Deprecated40.package/TimeStamp.class/instance/squeak protocol/species.st
R Deprecated40.package/TimeStamp.class/instance/squeak protocol/storeOn_.st
R Deprecated40.package/extension/CheckBoxModel/instance/whenLabelChanged_.st
R Deprecated40.package/extension/Class/instance/name_.st
R Deprecated40.package/extension/CompiledMethod/instance/messagesDo_.st
R Deprecated40.package/extension/Date/instance/leap.st
R Deprecated40.package/extension/DateAndTime/instance/asTimeStamp.st
R Deprecated40.package/extension/ImageModel/instance/whenActionChanged_.st
R Deprecated40.package/extension/ImageModel/instance/whenImageChanged_.st
R Deprecated40.package/extension/LabelModel/instance/text.st
R Deprecated40.package/extension/LabelModel/instance/text_.st
R Deprecated40.package/extension/LabelModel/instance/whenLabelChanged_.st
R Deprecated40.package/extension/LabelModel/instance/whenTextChanged_.st
R Deprecated40.package/extension/Locale/class/addLocalChangedListener_.st
R Deprecated40.package/extension/Locale/class/isoLocale_.st
R Deprecated40.package/extension/Locale/class/localeChanged.st
R Deprecated40.package/extension/Locale/class/localeChangedListeners.st
R

Re: [Pharo-dev] [Pharo-users] [ANN] ArchLinux pharo-vm / pharo-launcher packages

2015-04-21 Thread Laurent




Le mar. 21 avril 2015 à 22:20, Sean P. DeNigris 
s...@clipperadams.com a écrit :

laurent laffont wrote

 it seems the Archlinux team does not have access to
 pharo-archlinux repository


Fixed.


Thanks. Branch pushed.

Laurent







-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ANN-ArchLinux-pharo-vm-pharo-launcher-packages-tp4749669p4820998.html
Sent from the Pharo Smalltalk Developers mailing list archive at 
Nabble.com.

Re: [Pharo-dev] Improving the documentation model

Nicolas Anquetil wrote
 I believe we can safely assume that if people are still using textual 
 interface after such a very long period (in computer science time 
 frame), it is most certainly because natural selection has favoured the 
 choice that had most advantages ...

By this rationale, we should all stop programming Smalltalk immediately in
favor of COBOL ;)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Improving-the-documentation-model-tp4820814p4821001.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Center morph in a morph


 On 21 Apr 2015, at 22:36, Sean P. DeNigris s...@clipperadams.com wrote:
 
 Uko2 wrote
 I’ve tried to use:
 listCentering: #center;
 ...
 with TableLayout
 
 That worked for me...
 http://forum.world.st/file/n4821006/Screenshot_2015-04-21_16.png 
 
 You sent #listCentering to the parent Morph, right?
 
 BTW for exploration, a really easy way to see what these do it to play with
 them via the red halo (in the Layout sub-menu)…

Wow, I’ve never thought about this. Thanks, I’ve figured out my problem

 
 
 
 -
 Cheers,
 Sean
 --
 View this message in context: 
 http://forum.world.st/Center-morph-in-a-morph-tp4820943p4821006.html
 Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Pharo5] All systems on go!

2015-04-21 Thread Nicolai Hess

2015-04-21 22:47 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I cant see pharo classes in Nautiluse apart from a few, unless i open them
 with GTSpotter , then they get added to Nautilus. Is this normal ? Is it
 because I miss the sources file ? and if yes where I find it ?


No, there is an active package pane filter. I thnk this happend by
accident, the field should be empty.




 On Tue, Apr 21, 2015 at 11:30 PM, Sean P. DeNigris s...@clipperadams.com
 wrote:

 Thanks, Marcus!! :)



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Pharo5-All-systems-on-go-tp4820956p4821002.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] [Pharo-users] [ANN] ArchLinux pharo-vm / pharo-launcher packages

laurent laffont wrote
 it seems the Archlinux team does not have access to 
 pharo-archlinux repository

Fixed.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ANN-ArchLinux-pharo-vm-pharo-launcher-packages-tp4749669p4820998.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] PharoLauncher all white !!!

I just downloaded latest pharolauncher from here

https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/lastSuccessfulBuild/artifact/Pharo_0.2.7.dmg

The new PL is all white, is this normal ? I cant see the panels to resize
them all see is white and the text.

[Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding accents

2015-04-21 Thread Leo Paniceres

Hi
I’m experiencing a problem when I try to encode an URL with latin 
characters with accents or circumflex.
The example is:

   ZnPercentEncoder new decode: 'Neuquén, Neuquén Province, Argentina'
 

The IETF standard  provides these definitions:

https://www.ietf.org/rfc/rfc3986.txt

https://tools.ietf.org/html/std63

 

 the implementation   ZnPercentEncoder, decode: stringStream to: byteStream 
could be changed to accept characters below 256. (char charCode  256 instad of 
char charCode  128)?

 

decode: stringStream to: byteStream

| char |

self decodePlusAsSpace.

[ stringStream atEnd ]

   whileFalse: [

   ((char := stringStream next) == $+ and: [ 
decodePlusAsSpace ])

   ifTrue: [ byteStream nextPut: 32 
]

   ifFalse: [ 

  char == $%

  ifTrue: [ 
byteStream nextPut: (self readHexFrom: stringStream) ]

  ifFalse: [


  char charCode  128


 ifTrue: [ byteStream nextPut: char charCode ]


 ifFalse: [ self errorAsciiCharacterExpected ] ] ] ]

Re: [Pharo-dev] Improving the documentation model

for the record this is something I am interested into contributing. It
would be great if we coordinate effort . I don't make big promises but I
can definitely spare some hours or even days. I am in the process of
documenting Morphic and I definitely want something more interactive
something more Pharo ;)

On Wed, Apr 22, 2015 at 12:01 AM Sean P. DeNigris s...@clipperadams.com
wrote:

 philippeback wrote
  Pillar is fine as long as we aren't forced into the backend quirks to get
  a
  given output.

 This is actually much more productive than I thought it would be :) We've
 identified some key intentions:
 - easy to version
 - easy to contribute
 - live (whether preview rendering or model being worked on)
 - portable (to other formats); i.e. not tied to one backend; I would add
 here that any syntax is just a serialized, dead form of the live model,
 which is what I really want to think about
 - easy to use for beginners (like WYSIWYG, live help)
 - pathway to efficient use for experts (a la command line, shortcuts,
 gestures; not mouse selection)

 That's a really great list. And WYSIWYG and Pillar are two different
 explorations into that problem space. But there is no point trying to
 convince through words, only to produce your favored approach that adresses
 those points more effectively than the other approach, or maybe we end up
 with two amazing approaches, like emacs and vim and we can happily debate
 forever ;)



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Improving-the-documentation-model-tp4820814p4821009.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] [Pharo-users] [ANN] ArchLinux pharo-vm / pharo-launcher packages

2015-04-21 Thread Laurent




Le mar. 21 avril 2015 à 1:46, Sean P. DeNigris s...@clipperadams.com 
a écrit :

laurent laffont wrote

  Feel free to create it and give me access I will use this new
 project as main repo.


https://github.com/pharo-project/pharo-archlinux
I sent you an invitation...


Thanks Sean. But it seems the Archlinux team does not have access to 
pharo-archlinux repository


Laurent







-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ANN-ArchLinux-pharo-vm-pharo-launcher-packages-tp4749669p4820730.html
Sent from the Pharo Smalltalk Developers mailing list archive at 
Nabble.com.

Re: [Pharo-dev] Improving the documentation model


On 21/04/15 18:18, Dmitri Zagidulin wrote:

I strongly believe that the WYSIWYG editing route is a fundamentally
worse approach for documentation (and textbooks) than text-based
formatting such as Pillar, Markdown and Asciidoc.


I have a lot of experience using both. The best experience I've had
using Framemaker. Comparing it to Word is a soemwhat similar
experience to explaining non-smalltalkers about image-based development.


Specifically, it will result in less community contribution, and it will
make distributed version control of documents much harder.


There is actually no reason why that should be the case, especially
when using semantic markup. I agree that there are lots of WYSIWYG
programs that make it difficult.


Instead of going the route that you propose (which essentially attempts
to Word or Google Docs in-image),


My worst experiences with large documents were using Word.
It is designed for small documents, and it took Microsoft 10 years
to make bullet lists work.


Side-by-side instant preview makes it possible to have the best of both
worlds, text-based markup and WYSIWYG, without the typical WYSIWYG
drawbacks (of making distributed version control difficult, first and
foremost).


I have used side-by-side instant preview since it became available
(Textures on a Macintosh SE/30). Nice for maths, not for large documents.


2) Version control, especially with more than one or two collaborators,
is a *nightmare* with WYSIWYG tools. Look at what the state of the art
is, at what Microsoft's Word and Google's Docs have been able to
accomplish, in terms of revision control.


Neither are state of the art. Both are designed for small documents.


Despite unimaginable amounts of person-hours of development put into it,
it's pretty much unusable


I fully agree that the collaboration features of Word are unusable.
Word is feature checklist driven.


We are not Microsoft or Google. We are not going to solve the WYSIWYG
source control / version control problem better than they are.




4) The ability to render source text-based markup into multiple formats
(PDF, HTML, etc), is *essential*. Going from WYSIWYG to HTML is
impossible (all attempts to do so, by Microsoft, Adobe, etc, have
utterly failed).


Repurposing is something  Adobe still sells Framemaker for on Windows.
Works perfectly fine. Even has an API.


Whereas going from text-based to print/PDF is very
doable (see LaTeX, the entirety of HTML ecosystem, Pillar, etc).
This is a serious problem that FrameMaker never had to solve.


It is solved by Framemaker. That is an expensive product,
so there are not too many people knowing it.

Stephan

Re: [Pharo-dev] Improving the documentation model

And just to be clear, I am not against GUIs, specifically.

I'm against GUIs for distributed version control for collaborating on
documentation.

And only because I haven't seen it done in a usable fashion (again, see
Revision Control in Word or Google Docs). I'm always willing to be proven
wrong on that count, if some amazing tech comes along.

On Tue, Apr 21, 2015 at 3:48 PM, kilon alios kilon.al...@gmail.com wrote:

 Its funny you mention natural selection an extremely stupid and slow
 process. Fortunately for us software evolves with artificial selection
 which way faster and way more intelligent. But still it comes with a great
 deal of flaws when you take a look at what exactly is popular in the coding
 world nowdays . Or even outside the coding world. But yes we can sit here
 and debate this for million of years.

 I am not a GUI zealot though, I have my own opinion that I never try to
 enforce on others. I am perfectly ok with people that prefer a text based
 approach. The only thing I am saying that GUIs have one undisputed
 advantage, they are not text based only ;)

 For me it comes down to making sensible convenient and practical useful
 UIs. How you do it , graphical or text based is secondary concern.

 I am also aware of the fact that GUIs tend to be more difficult to create,
 which provides a very good explanation why command lines are still quite
 popular.

 On Tue, Apr 21, 2015 at 9:48 PM, Nicolas Anquetil 
 nicolas.anque...@inria.fr wrote:


 This remind me of a discussion a very long time ago on a newsgroup

 - a young zealot of GUI (windows, buttons, mouses) was asking himself and
 the community how people could deny that this was the best interface on
 earth or how anybody could prefer text based interface

 - a seasonned sys. admin then started to explain all the clicks he had to
 perform to create one new user account. Result: for one new user some
 minutes of work
 He then added that he had to create HUMDREDS of user every year and was
 so very happy that he did not had to do it all by pointing and clicking but
 had some scripts to do it.

 So the answer to all this is that there are very good and valid reasons
 to prefer text to all the shiny interfaces of he world.
 And you don't even have to look very far to find some.

 As for programming with in a graphical way, the ability has been around
 for decades.
 I believe we can safely assume that if people are still using textual
 interface after such a very long period (in computer science time frame),
 it is most certainly because natural selection has favoured the choice that
 had most advantages ...

 nicolas

 PS: which does not mean that GUI are completely useless


 On 21/04/2015 20:03, kilon alios wrote:

   Funnily enough I am in the exact opposite opinion, of Graphical
 approach being vastly superior to text based approach including programming
 languages. 25 years using computers and coding with them and still cannot
 fathom why programming languages are still a think and why developers and
 power users rely so much on text based approach. But whether I like it or
 not the coding world is dominated by text based solutions.

  Its a pointless debate though when it comes to pharo will depend on the
 people doing the work. Personally I don't have the time of going very deep
 into this and doing all the hard work it requires. My focus is elsewhere.
 But I welcome any contribution.

  As a lawyer myself and a coder, I cannot even begin to compare Latex to
 the convenience of Libreoffice I use at work. Its not even a debate .
 Latex is something I never heard of until  Pillar introduced me to it.
 Can't imagine who in the right mind would use this to document things, but
 I guess they have their reasons.

  I started with command line and CP/M back in 1988 but even back then
 when GUIs were not mainstream (at least in my country) I was dreaming of
 graphical intefaces that would lift me from the restrictions of text based
 approach and the dreaded command line. I wish I had found out about
 Smalltalk back then and its elegant solution to this problem.

  I love Pillar because its simple and I like the syntax, but yeah in the
 end I would choose a Graphical Documentation Tool no questions asked.

 On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin dmi...@zagidulin.net
 wrote:

  On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris 
 s...@clipperadams.com wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in
 various
 forms of assembly code.


  Completely disagree, that it's a regression in any way :)  Text-based
 document writing has enabled so many more features than WYSIWYG approaches
 have ever dreamed of. I would be happy to debate the merits of the two
 approaches, feature-for-feature.

  You're basically pining for the equivalent of VisualBasic drag  drop
 programming, versus the flexibility of writing code in an editor. The
 latter

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread nacho

I think we have to distinguish two things.
One thing is GUI only with mouse. Another one is GUI with lots of keyboard
shortcuts and bindings.
For instance. I use a lot of Excel which clearly is a GUI app but I seldom
use the mouse it is much productive for me to use shortcuts.
An analogy can be made between Python an Pharo.
Python is great, but one of the things that really annoys me is that all
the methods, clases are there in a way which is difficult to grasp them. On
the other hand, the System Browser is a wonderful thing for an OO language.
GUI Zealot yes, mouse Zealot definitely not.
Cheers
Nacho


*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*

*Tel: (011) 4542-6714*



















On Tue, Apr 21, 2015 at 4:35 PM, kilon.alios [via Smalltalk] 
ml-node+s1294792n4820989...@n4.nabble.com wrote:

 Its funny you mention natural selection an extremely stupid and slow
 process. Fortunately for us software evolves with artificial selection
 which way faster and way more intelligent. But still it comes with a great
 deal of flaws when you take a look at what exactly is popular in the coding
 world nowdays . Or even outside the coding world. But yes we can sit here
 and debate this for million of years.

 I am not a GUI zealot though, I have my own opinion that I never try to
 enforce on others. I am perfectly ok with people that prefer a text based
 approach. The only thing I am saying that GUIs have one undisputed
 advantage, they are not text based only ;)

 For me it comes down to making sensible convenient and practical useful
 UIs. How you do it , graphical or text based is secondary concern.

 I am also aware of the fact that GUIs tend to be more difficult to create,
 which provides a very good explanation why command lines are still quite
 popular.

 On Tue, Apr 21, 2015 at 9:48 PM, Nicolas Anquetil [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=4820989i=0 wrote:


 This remind me of a discussion a very long time ago on a newsgroup

 - a young zealot of GUI (windows, buttons, mouses) was asking himself and
 the community how people could deny that this was the best interface on
 earth or how anybody could prefer text based interface

 - a seasonned sys. admin then started to explain all the clicks he had to
 perform to create one new user account. Result: for one new user some
 minutes of work
 He then added that he had to create HUMDREDS of user every year and was
 so very happy that he did not had to do it all by pointing and clicking but
 had some scripts to do it.

 So the answer to all this is that there are very good and valid reasons
 to prefer text to all the shiny interfaces of he world.
 And you don't even have to look very far to find some.

 As for programming with in a graphical way, the ability has been around
 for decades.
 I believe we can safely assume that if people are still using textual
 interface after such a very long period (in computer science time frame),
 it is most certainly because natural selection has favoured the choice that
 had most advantages ...

 nicolas

 PS: which does not mean that GUI are completely useless


 On 21/04/2015 20:03, kilon alios wrote:

   Funnily enough I am in the exact opposite opinion, of Graphical
 approach being vastly superior to text based approach including programming
 languages. 25 years using computers and coding with them and still cannot
 fathom why programming languages are still a think and why developers and
 power users rely so much on text based approach. But whether I like it or
 not the coding world is dominated by text based solutions.

  Its a pointless debate though when it comes to pharo will depend on the
 people doing the work. Personally I don't have the time of going very deep
 into this and doing all the hard work it requires. My focus is elsewhere.
 But I welcome any contribution.

  As a lawyer myself and a coder, I cannot even begin to compare Latex to
 the convenience of Libreoffice I use at work. Its not even a debate .
 Latex is something I never heard of until  Pillar introduced me to it.
 Can't imagine who in the right mind would use this to document things, but
 I guess they have their reasons.

  I started with command line and CP/M back in 1988 but even back then
 when GUIs were not mainstream (at least in my country) I was dreaming of
 graphical intefaces that would lift me from the restrictions of text based
 approach and the dreaded command line. I wish I had found out about
 Smalltalk back then and its elegant solution to this problem.

  I love Pillar because its simple and I like the syntax, but yeah in the
 end I would choose a Graphical Documentation Tool no questions asked.

 On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=4820989i=1 wrote:

  On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=4820989i=2 wrote:

 I dream that all documents in my Dynabook are WYSIWYG.

Re: [Pharo-dev] [Pharo5] All systems on go!

yeap that was it, it now displays all , thank you Nicolai :)


On Wed, Apr 22, 2015 at 12:00 AM Nicolai Hess nicolaih...@web.de wrote:

 2015-04-21 22:47 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I cant see pharo classes in Nautiluse apart from a few, unless i open
 them with GTSpotter , then they get added to Nautilus. Is this normal ? Is
 it because I miss the sources file ? and if yes where I find it ?


 No, there is an active package pane filter. I thnk this happend by
 accident, the field should be empty.




 On Tue, Apr 21, 2015 at 11:30 PM, Sean P. DeNigris s...@clipperadams.com
  wrote:

 Thanks, Marcus!! :)



 -
 Cheers,
 Sean
 --
 View this message in context:
 http://forum.world.st/Pharo5-All-systems-on-go-tp4820956p4821002.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.

Re: [Pharo-dev] Improving the documentation model

philippeback wrote
 Pillar is fine as long as we aren't forced into the backend quirks to get
 a
 given output.

This is actually much more productive than I thought it would be :) We've
identified some key intentions:
- easy to version
- easy to contribute
- live (whether preview rendering or model being worked on)
- portable (to other formats); i.e. not tied to one backend; I would add
here that any syntax is just a serialized, dead form of the live model,
which is what I really want to think about
- easy to use for beginners (like WYSIWYG, live help)
- pathway to efficient use for experts (a la command line, shortcuts,
gestures; not mouse selection)

That's a really great list. And WYSIWYG and Pillar are two different
explorations into that problem space. But there is no point trying to
convince through words, only to produce your favored approach that adresses
those points more effectively than the other approach, or maybe we end up
with two amazing approaches, like emacs and vim and we can happily debate
forever ;)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Improving-the-documentation-model-tp4820814p4821009.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding accents

2015-04-21 Thread Sven Van Caekenberghe

Leo,

Are you sure you understand what percent encoding is ?

Check the class comment of ZnPercentEncoding, it has links to a Wikipedia 
article.

Did you see ZnPercentEncoderTests ?

Anyway, I would think this is what you want to do:

ZnPercentEncoder new encode: 'Neuquén, Neuquén Province, Argentina'.

= 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'

ZnPercentEncoder new decode: 
'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'. 

= 'Neuquén, Neuquén Province, Argentina'

Seems to work fine, no ?

What problem do you have with ZnUrl ?

Sven

BTW: this is a pharo-users question.

 On 21 Apr 2015, at 22:51, Leo Paniceres lpanice...@gmail.com wrote:
 
 Hi
 I’m experiencing a problem when I try to encode an URL with latin 
 characters with accents or circumflex.
 The example is:
 
 
    ZnPercentEncoder new decode: 'Neuquén, Neuquén Province, Argentina'
 
  
 The IETF standard  provides these definitions:
 
 https://www.ietf.org/rfc/rfc3986.txt
 
 https://tools.ietf.org/html/std63
 
  
  the implementation   ZnPercentEncoder, decode: stringStream to: byteStream 
 could be changed to accept characters below 256. (char charCode  256 instad 
 of char charCode  128)?
 
  
 decode: stringStream to: byteStream
 
 | char |
 
 self decodePlusAsSpace.
 
 [ stringStream atEnd ]
 
whileFalse: [
 
((char := stringStream next) == $+ and: [ 
 decodePlusAsSpace ])
 
ifTrue: [ byteStream nextPut: 
 32 ]
 
ifFalse: [
 
   char == $%
 
   ifTrue: 
 [ byteStream nextPut: (self readHexFrom: stringStream) ]
 
   
 ifFalse: [
 
   
 char charCode  128
 
   
ifTrue: [ byteStream nextPut: char charCode ]
 
   
ifFalse: [ self errorAsciiCharacterExpected ] ] ] ]

Re: [Pharo-dev] Improving the documentation model


On 21/04/15 18:09, Ralph Boland wrote:

...

and there is no easy to use WYSIWYG UI for LaTeX.

...

Why is Lyx not an easy to use WYSIWYG UI for LaTeX.


I'm not quite sure. I've tried it a few times and went back
to other LaTeX tools. The LaTeX language doesn't map
very well to mouse gestures I think.

Stephan

Re: [Pharo-dev] Launcher Mac CI - Broken Executable

Damien Cassou-2 wrote
 I don't know why it doesn't work for you :-(

0.2.7 works again! Although it appears to contain a pretty old VM as it
doesn't have a SDL2 plugin present...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Launcher-Mac-CI-Broken-Executable-tp4820123p4821043.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread Nicolai Hess

Am 21.04.2015 15:11 schrieb stephan step...@stack.nl:

 TL;DR: Some roadmap ideas. Looks like a lot of work.
 Comments and improvements welcome:
 We should replace the Pillar document format
 by a better one, suitable for WYSIWYG editing and
 creating long documents.

 ---

Nice idea, but


 With Athens and TxText we now have low level
 abstractions for dealing with cursor and selection,  fonts,
 rendering glyphs and having both on-screen and
 PDF output.


Let us focus on this and make it work. TxText is not ready yet. Athens font
rendering still has some issues.
(And even with the good old TextMorph, we can not even draw underlined Text
or sub/superscript)

Re: [Pharo-dev] Improving the documentation model




Stephan Eggermont wrote

We should replace the Pillar document format
by a better one, suitable for WYSIWYG editing and
creating long documents.

I dream that all documents in my Dynabook are WYSIWYG. However, the
computing world seems to have regressed into writing documents in various
forms of assembly code. I'd love to have what you are suggesting, but there
is too much time, energy, and most importantly emotion invested in Pillar to
convince a change. IMHO, the only course would be to collect the people who
agree with you, create what you are proposing on your own, and deliver it to
the community to see for themselves why it is a better way.


I do not care about pillar. I care about we have it, it is working and 
improving

and we can control it.
I care that soon we can have a good solution and do something else.
I do not have 10 years for the perfect solution but if you come with it, 
maintain it, enhance

and I can extend it in case you disappear then I buy it.


Stef

Re: [Pharo-dev] [Pharo5] All systems on go!

2015-04-21 Thread Tudor Girba

Thanks!

Doru

On Tue, Apr 21, 2015 at 7:10 PM, Marcus Denker marcus.den...@inria.fr
wrote:

 Hi,

 So finally everything seems to work for getting going on Pharo5… this
 means there will
 be regular at least one update per day (if issue are in the state of “fix
 to include” are
 available).

 Today I did #003 which included the unloading of the Deprecated package of
 the last version.

 Marcus




-- 
www.tudorgirba.com

Every thing has its own flow

Re: [Pharo-dev] Improving the documentation model





 With Athens and TxText we now have low level
 abstractions for dealing with cursor and selection,  fonts,
 rendering glyphs and having both on-screen and
 PDF output.


Let us focus on this and make it work. TxText is not ready yet. Athens 
font rendering still has some issues.
(And even with the good old TextMorph, we can not even draw underlined 
Text or sub/superscript)



+1

Re: [Pharo-dev] Improving the documentation model




Le 21/4/15 21:25, p...@highoctane.be a écrit :


Pillar is fine as long as we aren't forced into the backend quirks to 
get a given output.


I haven't see Docbook and Docbook-XML and XSL-FO mentioned. But these 
are working nicely too.


Lots of Linux docs are written with Docbook.

I've a client who outputs supercomplicated documents with XSL-FO.

A Pillar output to Docbook would be great.



should be a visitor :)

One must invest time in any choice to be really productive. WYSIWYG 
included.


FWIW LibreOffice equations are written much faster when one knows the 
text based language than with the point and click tools.


The best thing is an ability to render fast. Same as Smalltalk: fast 
feedback in order to iterate without a break in the flow.





Le 21 avr. 2015 20:03, kilon alios kilon.al...@gmail.com 
mailto:kilon.al...@gmail.com a écrit :


Funnily enough I am in the exact opposite opinion, of Graphical
approach being vastly superior to text based approach including
programming languages. 25 years using computers and coding with
them and still cannot fathom why programming languages are still a
think and why developers and power users rely so much on text
based approach. But whether I like it or not the coding world is
dominated by text based solutions.

Its a pointless debate though when it comes to pharo will depend
on the people doing the work. Personally I don't have the time of
going very deep into this and doing all the hard work it requires.
My focus is elsewhere. But I welcome any contribution.

As a lawyer myself and a coder, I cannot even begin to compare
Latex to the convenience of Libreoffice I use at work. Its not
even a debate .  Latex is something I never heard of until  Pillar
introduced me to it. Can't imagine who in the right mind would use
this to document things, but I guess they have their reasons.

I started with command line and CP/M back in 1988 but even back
then when GUIs were not mainstream (at least in my country) I was
dreaming of graphical intefaces that would lift me from the
restrictions of text based approach and the dreaded command line.
I wish I had found out about Smalltalk back then and its elegant
solution to this problem.

I love Pillar because its simple and I like the syntax, but yeah
in the end I would choose a Graphical Documentation Tool no
questions asked.

On Tue, Apr 21, 2015 at 7:39 PM, Dmitri Zagidulin
dmi...@zagidulin.net mailto:dmi...@zagidulin.net wrote:

On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris
s...@clipperadams.com mailto:s...@clipperadams.com wrote:

I dream that all documents in my Dynabook are WYSIWYG.
However, the
computing world seems to have regressed into writing
documents in various
forms of assembly code.


Completely disagree, that it's a regression in any way :)
 Text-based document writing has enabled so many more features
than WYSIWYG approaches have ever dreamed of. I would be happy
to debate the merits of the two approaches, feature-for-feature.

You're basically pining for the equivalent of VisualBasic drag
 drop programming, versus the flexibility of writing code in
an editor. The latter wins, no contest. (Now, that is not to
say that text-based code editing can't be /improved/ with
better IDE tools, that's what we're all about after all.)

Re: [Pharo-dev] New Download instructions (esp. for GNU/Linux)


Le 20 avr. 2015 à 20:23, Sean P. DeNigris a écrit :

 We revamped the download instructions to incorporate the new VM builds and
 platform all-in-ones. The biggest improvement was that GNU/Linux now has its
 own instruction page laying out the various options and gotchas. Of course
 we should continue to improve, but IMHO we have addressed the most
 persistent gotchas.
 
 Check out the pages: http://pharo.org/download and
 http://pharo.org/gnu-linux-installation (which is linked from the first)
 
 Next up: we'd like to use the OpenBuildService to build from sources for all
 supported GNU/Linux configurations. Help is welcome!
 

great work Sean! It was really something missing.
Thanks

smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] [Pharo5] All systems on go!

2015-04-21 Thread Marcus Denker

Hi,

So finally everything seems to work for getting going on Pharo5… this means 
there will
be regular at least one update per day (if issue are in the state of “fix to 
include” are 
available).

Today I did #003 which included the unloading of the Deprecated package of the 
last version.

Marcus

Re: [Pharo-dev] PharoLauncher all white !!!

Well I am not complaining , I definitely don't like hard coded colors :)

If none will I will take a look , its being sometime since I contributed to
PL.

On Tue, Apr 21, 2015 at 11:47 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-04-21 22:33 GMT+02:00 kilon alios kilon.al...@gmail.com:

 I just downloaded latest pharolauncher from here


 https://ci.inria.fr/pharo/view/Launcher/job/Launcher-Mac/lastSuccessfulBuild/artifact/Pharo_0.2.7.dmg

 The new PL is all white, is this normal ?


 Some hard coded values were removed from the Pharo3 theme
 and the theme default values are just white :)

 http://forum.world.st/PharoLauncher-and-Pharo-5-0-tp4820240p4820720.html


 I cant see the panels to resize them all see is white and the text.

Re: [Pharo-dev] Center morph in a morph

Uko2 wrote
 I’ve tried to use:
 listCentering: #center;
 ...
 with TableLayout

That worked for me...
http://forum.world.st/file/n4821006/Screenshot_2015-04-21_16.png 

You sent #listCentering to the parent Morph, right?

BTW for exploration, a really easy way to see what these do it to play with
them via the red halo (in the Layout sub-menu)...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Center-morph-in-a-morph-tp4820943p4821006.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Improving the documentation model


On 21/04/15 17:59, Damien Cassou wrote:


stephan step...@stack.nl writes:


TL;DR: Some roadmap ideas. Looks like a lot of work.
Comments and improvements welcome:
We should replace the Pillar document format
by a better one, suitable for WYSIWYG editing and
creating long documents.


I agree that Pillar is far from perfect. Do you propose to (1) start
something from scratch or to (2) improve Pillar? If you propose (1), how
much do you plan to spend each day and for how long before reaching
Pillar current's state? If you propose (2), you can start doing
something small today and finish the same day. With (2) you could
improve the current situation before we go to bed.


Well, this was a description of where I would like to go
on the map. My first question is, are there enough people who
want to go there too, or am I aiming in the wrong direction?
And if it is a desirable destination, what small experiments
can we do to verify the reachability, and get an idea of how
much work this would be.

Stephan

Re: [Pharo-dev] Improving the documentation model

I strongly believe that the WYSIWYG editing route is a fundamentally worse
approach for documentation (and textbooks) than text-based formatting such
as Pillar, Markdown and Asciidoc.

Specifically, it will result in less community contribution, and it will
make distributed version control of documents much harder.

That said, I will support whatever documentation format or tech stack that
the community adapts. Any documentation is better than none, regardless of
the underlying details. (Though I will always advocate for text-based
formats).

Instead of going the route that you propose (which essentially attempts to
Word or Google Docs in-image), I think we should:

* Extend Pillar. With a few more features, it can be on par with Markdown
and Asciidoc, and then eventually surpass it (and have nice Pharo-specific
features like detection and unit-testing of Pharo code blocks, etc).

* Invest in instant-preview tech, in-image. This is similar to what
PillarHub does, for example, by using the Ace online editor. Take a look at
the first screenshot in: http://pillarhub.pharocloud.com/hub/pillarhub/about
Side-by-side instant preview makes it possible to have the best of both
worlds, text-based markup and WYSIWYG, without the typical WYSIWYG
drawbacks (of making distributed version control difficult, first and
foremost).

I will attempt to explain my reasoning, both for text-based markup, and
against heavier WYSIWYG approaches.

1) With documentation (and textbooks), the number one goal and number one
virtue is: make it easy for people to contibute. This means two things --
the simplicity of the format (this is where LaTeX fails), and the ease of
distributed version control (merging, pull requests, reviews and commentary
on contributions).

Look at the explosion in community-generated documentation and content
(READMEs on repos, the entirety of Wikipedia) that has resulted from
*making it easy for people to contribute and edit collaboratively*.

2) Version control, especially with more than one or two collaborators, is
a *nightmare* with WYSIWYG tools. Look at what the state of the art is, at
what Microsoft's Word and Google's Docs have been able to accomplish, in
terms of revision control.

Despite unimaginable amounts of person-hours of development put into it,
it's pretty much unusable (I speak from extensive personal experience, both
from collaborating on technical and business documents using Word and Docs,
and from seeing my wife and her friends (who are professional authors)
struggle with Word's revision control systems while working with their
publishers).

We are not Microsoft or Google. We are not going to solve the WYSIWYG
source control / version control problem better than they are. We need to
focus where we spend our efforts. In contrast, text-based markup version
control is a solved problem.

3) The convenience of WYSIWYG can be provided with side-by-side instant
preview (again, see PillarHub and the numerous WYSIWYG instant-previews in
Markdown editors).

4) The ability to render source text-based markup into multiple formats
(PDF, HTML, etc), is *essential*. Going from WYSIWYG to HTML is impossible
(all attempts to do so, by Microsoft, Adobe, etc, have utterly failed).
Whereas going from text-based to print/PDF is very doable (see LaTeX, the
entirety of HTML ecosystem, Pillar, etc).
This is a serious problem that FrameMaker never had to solve.

5) Text-based markup is not primitive. You mention a comparison to HTML
1.0. This is apt, but in the opposite direction than you intend. 1.0 may
have been primitive. But it has evolved into HTML 5, which not only has
many semantics level content features, but is expressive enough that pretty
much all UIs are moving to it (operating systems, desktop app suites,
mobile devices, etc).

Pillar may be in a primitive state right now, but it already has some
decent semantics-level capability, and can have a lot more with
considerably less effort than it would take to evolve WYSIWYG tools.

And actually, the WYSIWYG approach is much closer to HTML 1.0 (in the sense
that, users have to indicate *semantic* intentions like emphasis by
selecting different fonts, versus something like HTML 4/5, where the actual
intention is declared (EMPH tags, QUOTE tags, etc).

6) You mention the two standards in document writing (Word and LaTeX), and
the drawbacks to each. I completely agree there. There is a third option,
however, on which the world of open-source community technical writing is
standardizing. And it involves text-based markup languages:

* Markdown (in the form of https://www.gitbook.com/ )

* Asciidoc (more specifically, the Asciidoctor http://asciidoctor.org/ text
processor and publishing toolchain). Take a look at
https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272
for example.

* Pillar (that's us).

7) Text-based markup formats (aside from LaTeX) actually possess all of the
desired features that you mention, that are required to

Re: [Pharo-dev] Interrupt a locked pharo image from outside

Thierry Goubier wrote
 OSProcess 4.5.13 has a tendancy to lock the image on some linux systems

Total shot in the dark, but IIRC setting PipeableOSProcess output to non
blocking fixes many lockup scenarios



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Interrupt-a-locked-pharo-image-from-outside-tp4820842p4820925.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Recommended image resolution for Pillar books?

2015-04-21 Thread Damien Cassou


Dmitri Zagidulin dmi...@zagidulin.net writes:

 How would one do that? Does the width attribute take HTML style parameters
 (px, %)?

in the Pillar chapter of EnterprisePharo, I give an example:

+Caption of the picturefile://figures/pier-logo.png|width=50+

50 means half of the line width. Currently, there is no way to specify
something in px.

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/PillarChap/Pillar.pillar.html

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

Success is the ability to go from one failure to another without
losing enthusiasm. --Winston Churchill

Re: [Pharo-dev] Roadmap

2015-04-21 Thread Richard Sargent

Dmitri Zagidulin wrote
 Similar question - are there any roadmap plans to add Dictionary literals
 to Pharo?

Please be careful of complicating the language syntax. Perhaps the better
solution is to improve the optimizer until it can recognize the fact that
the expression really is constant and can inline the generated code.

I had an interesting lesson in this just the other day from Martin McClure.
I had been asking for a feature like VA Smalltalk's compile-time constant.
I am now convinced that is not the way to go.



 On Mon, Apr 20, 2015 at 1:20 PM, stepharo lt;

 stepharo@

 gt; wrote:
 


 Le 20/4/15 16:39, Dmitri Zagidulin a écrit :

 I would love to see two things in Pharo 5:

  1) Fix for mouse scrolling (at least on Mac OS X, though I think it does
 the same on Linux etc) in the class pane. While mouse-scrolling (either
 via
 a mouse wheel or two-finger scrolling on the touchpad) through the
 classes,
 the focus frequently and erratically jumps to the package pane, and the
 package pane starts scrolling instead. The focus also sometimes jumps
 when
 you reach the end of the class list (and, again, the package pane starts
 scrolling instead).


 Yes


  2) A button in the debugger that copies the error message to the
 clipboard (you can sort of do it currently by editing the title of the
 error window, but that's really awkward).


 it should be easy to do.


  I also have a question. Are there currently any roadmap plans for
 namespaces or modules for Pharo? I saw a brief discussion about it a few
 years back (http://forum.world.st/Pharo-and-Namespaces-td4636635.html ),
 and wanted to see if it's still on the table.


 Yes but not for Pharo 50.

 Stef




 On Mon, Apr 20, 2015 at 2:58 AM, stepharo lt;

 stepharo@

 gt; wrote:

 Hi

 if you have suggestions please let us know. Now usually suggestions
 often
 comes with time allocation ;)
 We have definitively a list of points we want to see addressed.

 Stef

 Le 19/4/15 23:19, Torsten Bergmann a écrit :

  Do we have a roadmap for Pharo 5 already?













--
View this message in context: 
http://forum.world.st/Roadmap-tp4820561p4820934.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Improving the documentation model

Stephan Eggermont wrote
 We should replace the Pillar document format
 by a better one, suitable for WYSIWYG editing and
 creating long documents.

I dream that all documents in my Dynabook are WYSIWYG. However, the
computing world seems to have regressed into writing documents in various
forms of assembly code. I'd love to have what you are suggesting, but there
is too much time, energy, and most importantly emotion invested in Pillar to
convince a change. IMHO, the only course would be to collect the people who
agree with you, create what you are proposing on your own, and deliver it to
the community to see for themselves why it is a better way.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Improving-the-documentation-model-tp4820814p4820935.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Center morph in a morph

Hi, I guess this is similar to vertical css centering question :)

I’ve tried to use:
cellPositioning: #center;
listCentering: #center;

with TableLayout but morphs are still positioned at the top of parent morph. 
Can I somehow put them in the middle (vertically)?

Uko

Re: [Pharo-dev] Improving the documentation model

On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris s...@clipperadams.com
wrote:

 I dream that all documents in my Dynabook are WYSIWYG. However, the
 computing world seems to have regressed into writing documents in various
 forms of assembly code.


Completely disagree, that it's a regression in any way :)  Text-based
document writing has enabled so many more features than WYSIWYG approaches
have ever dreamed of. I would be happy to debate the merits of the two
approaches, feature-for-feature.

You're basically pining for the equivalent of VisualBasic drag  drop
programming, versus the flexibility of writing code in an editor. The
latter wins, no contest. (Now, that is not to say that text-based code
editing can't be /improved/ with better IDE tools, that's what we're all
about after all.)

Re: [Pharo-dev] Improving the documentation model

2015-04-21 Thread Ralph Boland

...
 and there is no easy to use WYSIWYG UI for LaTeX.
...

Why is Lyx not an easy to use WYSIWYG UI for LaTeX.


Ralph Boland

[Pharo-dev] [ANN]: AconcaguaAddOns