- Pharo-users - lists.pharo.org

Tables in Pillar
by phil＠highoctane.be April 3, 2016

April 3, 2016

How is one doing a cell with content wrapping on multiple lines? With the | X | Y | abcd | some very long text that should be wrapping but apparently doesn't. So it is very annoying when one attempts to describe a long thing, which is one purpose for a table. I get one single line for each entry. How to do that? TIA Phil

7 12

STON UUID in the key
by Peter UhnÃ¡k April 2, 2016

April 2, 2016

Why does this fail? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ STON fromString: ( STON toStringPretty: (Dictionary with: UUID new -> nil) ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I would assume that if it can be serialized, then it should be also parsable. Having scalars for keys is JSON (and JavaScript) limitation because it's stupid, but if Smalltalk can have any hashable object for key (so any object), then it should be also possible to STON it in/out. Would this be hard to change? Peter

2 2

Re: [Pharo-users] OpenGL project
by Thibault Raffaillac April 1, 2016

April 1, 2016

There's (hopefully!) no question of throwing it away already. That represents too much work, and pretty good design choices IMO. Yet I'm still pretty new to Pharo/Smalltalk so simply need time. At the moment I am only practicing on a GLFW binding. Now, I do believe in OpenGL and hardware rendering in general (vs software & framebuffer stuff), but these APIs are constantly evolving (with hardware, market needs, ...), with driver manufacturers having little care about backward compatibility. This means in that sea of innovations we have to spot the few key technologies which are going to last long enough to be still in use by the time they reach Pharo users (think of tesselation, or geometry shaders, hardly heard of nowadays). OpenGL ES 2 is such a key tech, I think, for its wide adoption in Android, iOS, RasPi. Still, there is no doubt it is going to be ditched too in a decade or so (command buffers are already being reintroduced in Vulkan...), and then in Pharo. With that in mind, my point is to make it as few and small classes as possible, to make it easier (and faster!) to ditch them later when a new key tech arises. That said, I'm looking for least effort solution, so will still strive to replace NB with UFFI in generator. Cheers, Thibault > Why cutting things down to a subset? > You have all specs on Opengl.org .. all you have to do today is to import > xml file and generate proper ffi calls. You can, of course, add support of > OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't > have to use it if you don't need it. Instead, if that feels too big - you > can do it smarter way: > - make package/subpackage/classes for ES edition and for full edition. > It shouldn't cause much trouble if you do it right. > Because throwing away is easiest part - but making something that will > serve for years .. harder, because tomorrow someone else can come and throw > your stuff away :) > OpenGL is around for years now.. and i don't think ES edition will replace > standard.. I would prefer to be able to access to full OpenGL > functionality, at a day i will need it.. why cutting things down? > > There's many ways to do things in smart way so, nothing will be lost. > If you don't want/can't maintain or support full OpenGL support - that's > another story. Then just don't call your project OpenGL - it will cause > confusion to those who expecting things to work out of the box, and finding > out it just OpenGL ES.. > > > > My advise is don't worry about backward compatibility , make it easy, make > > it simple. Don't be afraid to code some of it in C if you have to. > > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > > > > Yep, make it work. That's all what matters.

2 1

[ANN] OS-Linux-CentOS
by Torsten Bergmann April 1, 2016

April 1, 2016

Hi, the OS-xxx series with (so far) - OS-Windows - OS-Linux-Ubuntu - OS-Unix - OS-Raspbian now has a new member called "OS-Linux-CentOS" which is more or less an adopted/customized pendant to "OS-Linux-Ubuntu". Project page is at http://www.smalltalkhub.com/#!/~OS/OS-Linux-CentOS Ready for Pharo 5. As ever you can load from Catalog tool or directly by entering "CentOS" into the Spotter search tool. Enjoy the video: https://www.youtube.com/watch?v=nAwtVeoll_k Bye T.

4 3

[ANN] Search and open Unix man pages in Pharo (using OSUnix project)
by Torsten Bergmann April 1, 2016

April 1, 2016

I added the possibility to search and open Unix man pages (commands, functions and header files) directly from Pharo Spotter. You will find it in the updated version of my OSUnix support package in catalog (Pharo 5) https://www.youtube.com/watch?v=81eehVO14KU Have fun T.

2 1

SMTPCLient vs Exchange smtp - always timeout
by Robert Kuszinger April 1, 2016

April 1, 2016

Hello! I'm trying to send an email with SMTPClient. It always stop with timeout here (Data receive timed out): *waitForDataFor: timeout "Wait for the given nr of seconds for data to arrive. Signal a time out or connection close exception if either happens before data becomes available." ^self waitForDataFor: timeout ifClosed: [ConnectionClosed signal: 'Connection closed while waiting for data.'] ifTimedOut: [ConnectionTimedOut signal: 'Data receive timed out.']* Test code from the Playground is at the end. The server is Exchange. I've tested with bare hand telnet connection, it works well. I was able to create email through telnet and send it. But the SMTPClient in pharo always runs to timeout. Others: last message in SMTPClient ( firstLine := self stream nextLine. I saw in debugger) fetchNextResponse "The FTP and similar protocols allow multi-line responses. If the response is multi-line, the fourth character of the first line is a $- and the last line repeats the numeric code but the code is followed by a space." | response result firstLine | result := '' writeStream. * firstLine := self stream nextLine.* [.... *]* Last response from server: (lastResponse instance variable): *354 Start mail input; end with <CRLF>.<CRLF>* (copied from debugger) This is why I forced CRLF... at the end of the message.... It seems to wait a response after sending the data.... Is there any idea what else to check? Thanks: Robert ------------------------------------ Playground code (yes, port 26) *SMTPClient* deliverMailFrom: 'info(a)sender.hu' to: #(' laszlo.gombas(a)recipient.hu') text: ' To: <info(a)sender.hu> From: <laszlo.gombas(a)recipient.hu> Subject: this is a test Hello! ÃRVÃZTÅ°RÅ TÃKÃRFÃRÃGÃP ',Character cr asString,Character lf asString,'.' ,Character cr asString,Character lf asString usingServer: '10.0.0.31:26'.

1 0

Re: [Pharo-users] OpenGL project
by Thibault Raffaillac April 1, 2016

April 1, 2016

> Can you include a proper build script? Yep sorry, here are the steps I used to make it run on OSX: $ brew install glfw3 $ cc demo.c -lglfw3 -framework OpenGL For other systems the doc is hopefully detailed enough (http://www.glfw.org/docs/latest/build.html) > Why do you say ?porting NBOpenGL?? Is it just a matter of rewriting the > native calls with the new FFI system? NBOpenGL functions were generated automatically from NBGLGenerator, so I need to get used to the tool beforehand. It looks like a lot of work was put into this, can I find a paper about it? Also, IMO this all looks too complex. My point in limiting to ES 2 is not just removing functions, I want to make it look simple like the C demo! Thibault

4 3

Spotter Survey
by Andrei Chis March 31, 2016

March 31, 2016

Hello everybody, We are conducting a small survey about Spotter. It would help us if you would complete the survey at: http://spotter.limequery.com/index.php/216683/lang-en We will use the data from this survey both in a research tasks and to help us to further improve Spotter. The survey should take you less than 5 minutes to complete. Thanks for your help! Cheers, Andrei

7 6

[ANN] OS-Windows 2.1 project updated for Pharo 5 (NB to UFFI transition)
by Torsten Bergmann March 31, 2016

March 31, 2016

Hi, the "OS-Windows" package [1] from my "OS-xxx" Pharo goodies series [2] is providing better access to native Windows APIs and wraps Windows functionality for easier access/coding in Pharo (browser, console, processes, shell, window, GDI, ...). Some of you may know or use this package already. Up to the last provided stable version for Pharo 4 all my code and bindings were based on "old" NativeBoost (NB). With the transition away from NB over to new UniversalFFI (UFFI) within Pharo 5 it was necessary to port/migrate the code over to UFFI for all the OS-xxx projects. Work of the Windows port started when UFFI was still shaky (December) and in a separate repo [3]. It was not easy in the beginning, some headbanging against the wall and feeling like a crash test dummy was involved - basing the port on early UFFI code and without much documentation. Several UFFI issues had to be discussed with Esteban Lorenzano in private conversations on #slack: often leading to some updated UFFI versions afterwards and an updated worklog of Esteban [4]. In the Pharo spirit "step by step" all of this got analyzed, fixed, renamed, improved and integrated into latest Pharo 5 in the last months. Esteban was VERY VERY supportive and adopted UFFI for all the needs! ONCE AGAIN: A BIG THANK YOU, ESTEBAN!!! Long story short: I can now release "OS-Windows" again into the wild for Pharo 5: fully compatible, again with cleaner code, some more functionality and even more tests (from 77 to now 81) As ever it is easy to access: open spotter in Pharo 5 and load "OSWindows". Full docu is on the project page [1], the new version is fully compatible to the Pharo 4 version so there was no need to change a single line in the tutorial. ;) Have fun T. [1] http://www.smalltalkhub.com/#!/~OS/OS-Windows [2] http://www.smalltalkhub.com/#!/~OS [3] http://www.smalltalkhub.com/#!/~TorstenBergmann/NOS [4] http://log.smallworks.eu/

1 0

Spec ListModel synchronization
by Rob Rothwell March 31, 2016

March 31, 2016

Hello, It's been a while since I tried out Pharo. I always struggled with Morphic UI's, but I noticed Spec and there seemed to be enough examples floating around that I thought I'd give it another try. Is Spec "here to stay?" Is it worthwhile to figure it out? It seems like with the developing possibilities of OSWindow-SDL2, one might use Spec to compose native widgets as well. My main question is about synchronizing domain changes with a Spec UI. For example, if I create an empty list of items: aList := OrderedCollection new. And create and open a ListModel that uses that list: aListModel := ListModel new items: aList; openWithSpec; yourself. I get a nice empty list. If I add an item to my list: aList add: 1. Then I need to update the list with another: aListModel items: aList. To see it show up. Alternatively (this seems wrong), I can add an item to the ListModel listItems directly: aListModel items: (aListModel listItems add: 1; yourself). Is that basically what you need to do to maintain synchronization between your domain list and the Spec UI representation of that list, or am I missing something? Thank you, Rob

4 4