April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Improving the documentation model

by stepharo

> > > > 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

April 22, 2015

Re: [Pharo-dev] Improving the documentation model

by stepharo

Le 21/4/15 21:25, phil(a)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.alios(a)gmail.com > <mailto:kilon.alios@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 > <dmitri(a)zagidulin.net <mailto:dmitri@zagidulin.net>> wrote: > > On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@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.) > >

April 22, 2015

Re: [Pharo-dev] Improving the documentation model

by stepharo

> 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

April 22, 2015

Integration process in presence of "external" project

by stepharo

Esteban I was thinking about the following this night. While I understand that we want configuration only it will slow us down like hell. Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages. Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change Stef

April 22, 2015

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

by Tudor Girba

Could JB describe the problem with Metacello? Perhaps there is a workaround. Doru On Tue, Apr 21, 2015 at 3:27 PM, stepharo <stepharo(a)free.fr> wrote: > > 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 SPH&epidemiological 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 > >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2015

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

by Marcus Denker

> On 21 Apr 2015, at 22:58, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-04-21 22:47 GMT+02:00 kilon alios <kilon.alios(a)gmail.com <mailto:kilon.alios@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. > > yes, saw it alreadyâ¦ we should add that #cleanUp resets it. Marcus

April 22, 2015

Re: [Pharo-dev] Improving the documentation model

by Nicolai Hess

Am 21.04.2015 15:11 schrieb "stephan" <stephan(a)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)

April 22, 2015

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

by Tudor Girba

Thanks! Doru On Tue, Apr 21, 2015 at 7:10 PM, Marcus Denker <marcus.denker(a)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"

April 22, 2015

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

by Sean P. DeNigris

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.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 22, 2015

Re: [Pharo-dev] Improving the documentation model

by Stephan Eggermont

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

April 21, 2015