Re: [Pharo-users] FileReference>>#moveTo: across filesystems

[Alistair Grant]

On 13 November 2017 at 19:11, Alistair Grant  wrote:
> Hi Claudio,
>
> On 13 November 2017 at 18:49, Claudio Corrodi  wrote:
>> Hi all,
>>
>> Manuel Leuenberger and I ran into an issue with the FileReference>>#moveTo:
>> method last week. On my system, I have "/" and "/home" in two different
>> partitions/file systems. If I do something like the following, Pharo
>> complains with a PrimitiveFailed signal:
>>
>> '/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt'
>> asFileReference
>>
>> I do not know how this is implemented exactly, but assume that the "rename"
>> syscall is used (on Linux systems, that is), which does not work across file
>> systems. The issue does not arise if I moveTo: inside the same filesystem.
>>
>> Is this expected behaviour? It is not obvious (to me) that
>> FileReference>>#moveTo: requires source and target to be on the same
>> filesystem. It would therefore make more sense to me if there were a
>> fallback that copies and deletes if two filesystems are involved (much like
>> "mv" behaves).
>>
>> What do you think?
>>
>> Cheers,
>> Claudio
>
> This issue was fixed some time ago.  I'm having trouble finding the
> fogbugz issue, but it is definitely fixed in Pharo 7.


For future reference: https://pharo.fogbugz.com/f/cases/20172



> Would you
> please let me know which build of Pharo you are using, and take a look
> at FileSystem>>move:to: and compare it to (minus the formatting
> changes :-)):
>
> move: sourcePath to: destination
> "Move the file /directory referenced as sourcePath to the destination
> referred as destPath.
> If there is no file at sourcePath, raise FileDoesNotExist.
> If destPath is a file, raise FileExists.
> If destPath is a directory, move the sourcePath in to the directory"
>
> | fullDestination |
>
> destination isFile ifTrue: [ FileExists signalWith: destination ].
> destination isDirectory
> ifTrue: [ fullDestination := destination / sourcePath basename ]
> ifFalse: [ fullDestination := destination ].
> self = destination fileSystem ifTrue:
> [
> "Ideally we would test whether the source and destination are on the
> same filesystem from the OSs perspective.
> Since we can't do that, just try rename, and if that fails, copy and delete."
> [ self rename: sourcePath to: fullDestination resolve path ]
> on: Error
> do: [ :error | self copyAndDelete: sourcePath to: fullDestination ].
> ] ifFalse:
> [ self copyAndDelete: sourcePath to: fullDestination ].
> ^fullDestination
>
>
> Cheers,
> Alistair

Re: [Pharo-users] Stream API

[Pavel Krivanek]

2017-11-13 23:51 GMT+01:00 Norbert Hartl :

>
>
> > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse  >:
> >
> >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 
> wrote:
> >> The idea is to have much simpler streams which can be composed to get
> more sophisticated behaviour.
> >>
> >> The most primitive streams should be binary read or write streams, like
> a raw file or network connection.
> >>
> >> To add a character encoding/decoding you wrap them in a
> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer,
> cleaner ZnCharacterEncoders).
> >
> > Yes really nice :)
> >
> > And Guille started to use them and we are slowly rewriting all the
> > stream internal users to use Zn and after we will be free.
> >
> >
> No, you will depend on zinc classes. How is that supposed to work in
> bootstrap?
>

In bootstrap we already use the package 'Zinc-Character-Encoding-Core'. It
is standalone so there is no dependency issue.

-- Pavel


>
> Norbert
> >> If you want buffering, you wrap a ZnBufferedReadStream or
> ZnBufferedWriteStream around them.
> >>
> >> And there are some other examples in the system too.
> >>
> >> Have a look at BinaryFileStream and ZdcSocketStream.
> >>
> >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must
> die, because they try to be everything at once and are impossible to change.
> >
> >
> > YES YES YES and celebrate. I could never understand anything. My brain
> > is too limited for these kind of games :)
> >
> >
> >
> >> The contract of a stream should be much, much simpler than it is today.
> >
> > Fully agree.
> >
> >>
> >> For writing that means
> >>
> >> #nextPut:
> >> #nextPutAll:
> >> #next:putAll:
> >> #next:putAll:startingAt:
> >>
> >> the 3 last ones can be written in terms of of the first one, but the
> last one is key because it can be the most efficient.
> >> And maybe also
> >>
> >> #flush
> >> #close
> >>
> >> Some helpers for character writing are
> >>
> >> #space
> >> #tab
> >> #cr
> >> #crlf
> >> #lf
> >>
> >> Maybe #newline
> >
> > :)
> >
> >
> >>
> >> #<< is a handy method too.
> >>
> >> For reading that means
> >>
> >> #atEnd
> >> #next
> >> #next:
> >> #next:into:
> >> #next:into:startingAt:
> >> #nextInto:
> >> #peek
> >> #skip:
> >> #upToEnd
> >> #upTo:
> >> #readInto:startingAt:count:
> >>
> >> Again, they can all be written in terms of #next, but
> #readInto:startingAt:count: is the core, efficient one.
> >> Note that #peek allows a one character lookahead, which should be
> sufficient for almost all parsing needs.
> >>
> >> #close is also a necessary operation, #peekFor: a handy one, #nextLine
> is popular too.
> >>
> >> There is a discussion about positioning (#position , #position: and
> related) but these cannot be supported _in general_ by the kind of streams
> described above.
> >>
> >> If you absolutely need these, read #upToEnd and use a regular
> ReadStream (over a fixed collection).
> >>
> >> The collection based classic Streams should always remain in the
> system, they are too handy. But have you seen for example, #nextInt32 on
> PositionableStream ? Good luck with that when the the underlying collection
> is anything other than bytes.
> >>
> >> All this being said, there is no one, single correct answer.
> >>
> >> But if we all try to simplify what we expect of streams (use a more
> limited API), we'll be more nimble to make implementation changes later on.
> >>
> >> Sven
> >>
> >>> On 13 Nov 2017, at 19:58, Stephane Ducasse 
> wrote:
> >>>
> >>> Hi Evan
> >>>
> >>> I think that we will use the ZnStreams.
> >>> If we use Xtreams we will transform their API because some messages
> >>> are not really good.
> >>> Stef
> >>>
>  On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue 
> wrote:
>  I've heard mention once or twice on this list and in some release
> notes of
>  what sounded like possible coming changes to the stream API. Could
> anyone
>  point me to any concrete details about that? I haven't been able to
> dig
>  anything up myself by searching. I'm about to write something that
> I'd like
>  to be polymorphic with the stream API, but if that's about to change,
> I'd
>  like to plan ahead.
> 
>  Thanks,
>  Evan
> >>>
> >>
> >>
>
>

Re: [Pharo-users] Embedded PDF viewer?

[K K Subbu]

On Monday 13 November 2017 05:29 PM, Ben Coman wrote:
Yes, I've certainly considered it.  Pragmatically, in my electrical 
career I deal with a lot of single page A3 PDF scans of schematic 
drawings, so pre-converting to a bitmap format outside of Pharo wouldn't 
lose much.


PDF deals with vector graphics, so bitmap conversion will be lossy. You 
could import them as SVG instead use the existing classes for handling 
SVG and XML.


HTH .. Subbu

[Pharo-users] FFIExternalEnumeration int versus long

[Ben Coman]

I have a C definition...
  unsigned long FPDF_GetLastError();

whose return values are...
  #define FPDF_ERR_SUCCESS 0// No error.
  #define FPDF_ERR_UNKNOWN 1// Unknown error.
  #define FPDF_ERR_FILE 2   // File not found or could not be opened.
  #define FPDF_ERR_FORMAT 3 // File not in PDF format or corrupted.
  #define FPDF_ERR_PASSWORD 4   // Password required or incorrect
 password.
  #define FPDF_ERR_SECURITY 5   // Unsupported security scheme.
  #define FPDF_ERR_PAGE 6   // Page not found or content error.

I was thinking of turning those #define's into an FFIExternalEnumeration,
but I was wondering if I'll hit some undefined behaviour with the
underlying representation being a "long" rather than an "int" ?

I do see here that C enumerations can be a range of types including "long"
* https://stackoverflow.com/questions/7093360/c-sharp-enum-of-long-values
but I'm not sure how it works in the Pharo context to know what the size
underlying representation.

cheers -ben

[Pharo-users] when a subclass is loaded, is super-class-side>>initialize executed?

[Ben Coman]

Because I'm lazy to experiment this instant (not wanting to get distracted
from my current track), and also its probably a useful remainder for others
I'll just ask...

When MyClass is loaded, #initialize is sent to it.  Typically the
class-side>>initialize should not call "super initialize" to avoid
re-initializing the superclaass, but what if MyClass doesn't implement
#initialize?  Does the message fall through to the superclass, or is
#initialize only sent if MyClass implements it?

Concrete example...
FFIExternalEnumeration subclass MyEnumeration needs to be sent
#initializeEnumeration when it is loaded.  We have...

FFIExternalEnustmeration>>#initialize
self initializeEnumeration

so is MyEnumeration *required* to implement its own
MyEnumeration>>#initialize, or can it rely
FFIExternalEnustmeration>>#initialize.   I believe it is the former, but
just wanted to confirm my understanding.

cheers -ben

Re: [Pharo-users] Stream API

[Norbert Hartl]

> Am 13.11.2017 um 21:08 schrieb Stephane Ducasse :
> 
>> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe  wrote:
>> The idea is to have much simpler streams which can be composed to get more 
>> sophisticated behaviour.
>> 
>> The most primitive streams should be binary read or write streams, like a 
>> raw file or network connection.
>> 
>> To add a character encoding/decoding you wrap them in a 
>> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, 
>> cleaner ZnCharacterEncoders).
> 
> Yes really nice :)
> 
> And Guille started to use them and we are slowly rewriting all the
> stream internal users to use Zn and after we will be free.
> 
> 
No, you will depend on zinc classes. How is that supposed to work in bootstrap? 

Norbert
>> If you want buffering, you wrap a ZnBufferedReadStream or 
>> ZnBufferedWriteStream around them.
>> 
>> And there are some other examples in the system too.
>> 
>> Have a look at BinaryFileStream and ZdcSocketStream.
>> 
>> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, 
>> because they try to be everything at once and are impossible to change.
> 
> 
> YES YES YES and celebrate. I could never understand anything. My brain
> is too limited for these kind of games :)
> 
> 
> 
>> The contract of a stream should be much, much simpler than it is today.
> 
> Fully agree.
> 
>> 
>> For writing that means
>> 
>> #nextPut:
>> #nextPutAll:
>> #next:putAll:
>> #next:putAll:startingAt:
>> 
>> the 3 last ones can be written in terms of of the first one, but the last 
>> one is key because it can be the most efficient.
>> And maybe also
>> 
>> #flush
>> #close
>> 
>> Some helpers for character writing are
>> 
>> #space
>> #tab
>> #cr
>> #crlf
>> #lf
>> 
>> Maybe #newline
> 
> :)
> 
> 
>> 
>> #<< is a handy method too.
>> 
>> For reading that means
>> 
>> #atEnd
>> #next
>> #next:
>> #next:into:
>> #next:into:startingAt:
>> #nextInto:
>> #peek
>> #skip:
>> #upToEnd
>> #upTo:
>> #readInto:startingAt:count:
>> 
>> Again, they can all be written in terms of #next, but 
>> #readInto:startingAt:count: is the core, efficient one.
>> Note that #peek allows a one character lookahead, which should be sufficient 
>> for almost all parsing needs.
>> 
>> #close is also a necessary operation, #peekFor: a handy one, #nextLine is 
>> popular too.
>> 
>> There is a discussion about positioning (#position , #position: and related) 
>> but these cannot be supported _in general_ by the kind of streams described 
>> above.
>> 
>> If you absolutely need these, read #upToEnd and use a regular ReadStream 
>> (over a fixed collection).
>> 
>> The collection based classic Streams should always remain in the system, 
>> they are too handy. But have you seen for example, #nextInt32 on 
>> PositionableStream ? Good luck with that when the the underlying collection 
>> is anything other than bytes.
>> 
>> All this being said, there is no one, single correct answer.
>> 
>> But if we all try to simplify what we expect of streams (use a more limited 
>> API), we'll be more nimble to make implementation changes later on.
>> 
>> Sven
>> 
>>> On 13 Nov 2017, at 19:58, Stephane Ducasse  wrote:
>>> 
>>> Hi Evan
>>> 
>>> I think that we will use the ZnStreams.
>>> If we use Xtreams we will transform their API because some messages
>>> are not really good.
>>> Stef
>>> 
 On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue  wrote:
 I've heard mention once or twice on this list and in some release notes of
 what sounded like possible coming changes to the stream API. Could anyone
 point me to any concrete details about that? I haven't been able to dig
 anything up myself by searching. I'm about to write something that I'd like
 to be polymorphic with the stream API, but if that's about to change, I'd
 like to plan ahead.
 
 Thanks,
 Evan
>>> 
>> 
>> 

Re: [Pharo-users] Why is compile: breaking my image?

[Peter Uhnák]

Hi,

this is a bit more confusing than I originally thought. So let me elaborate
(this is not part of Pharo I've dabbled in before...)
(there's an issue 20212 for this)

The problem is somewhere in SyntaxErrorDebugger and probably
SyntaxErrorNotification.

Normally (by normally I mean according to the implementation) when an
syntax debugger is created, it is created in new process.
However when I close the window without saving, the process is not
terminated.

Some one has decided that SyntaxErrorDebugger>>release was not good enough,
so they've added a WindowClosed catch (in SyntaxErrorDebugger
class>>buildMorphicViewOn: ) that in turn calls
SyntaxErrorDebugger>>handleWindowClosed.

That probably fixed whatever the author was trying to fix, but it broke
overall.

The expected behavior should be:

1) when a debugger window appears and I close it, the process should
terminate -- it doesn't
2) when a debugger window appears and I enter a valid text and save it,
2.i) the process should terminate -- it doesn't
2.ii) the method should be compiled -- it compiles the original broken code

So something like this can happen

Something compile: '^^'.
* enter some correct code, e.g. 'method ^ 1' *
Something selectors "-> #(#method)"
(Something>>#method) sourceCode "-> '^^'"

I don't understand how this is even possible to have sourceCode that
doesn't include the selector.

3) when a debugger window appears and I enter invalid code, then it should
2.a) either terminate the previous process and launch a new process
containing the updated, but broken code
2.b) or not terminate and reuse the current process but display the new
broken code

right now it creates a new process, but doesn't terminate.

Peter

On Mon, Nov 13, 2017 at 9:42 PM, Guillermo Polito  wrote:

> Can you share what was the original problem and how you fixed it?
>
> On Sat, Nov 11, 2017 at 4:44 PM, Sven Van Caekenberghe 
> wrote:
>
>>
>>
>> > On 11 Nov 2017, at 16:33, Peter Uhnák  wrote:
>> >
>> > Never mind... I see now what is broken and I'll try to fix it (assuming
>> my P7 image won't corrupt itself due to FreeType before I manage to push
>> the changes... heh)
>>
>> You can now disable FreeType fonts and still use bitmapped Source Code
>> fonts.
>>
>> > On Sat, Nov 11, 2017 at 3:43 PM, Peter Uhnák  wrote:
>> > This applies to P61 (for some time) and P7.
>> >
>> > Object compile: '^'.
>> >
>> > Syntax Error popup -> close
>> >
>> > now you have two morphic UI processes running and World starts to get
>> corrupted with artifacts around. (and it also in one case manage to
>> actually corrupt the image to the point that I was no longer able to even
>> launch it).
>> >
>> > Peter
>> >
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 102

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> If you have many forms you may have a look at magritte the Morph
> builder does not work anymore but may be it is
> worth fixing it.

What's broken? I use it all the time. Maybe something I fixed should be
backported from my GH fork?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [Pharo-dev] Publishing a book with Pillar

[Julien]

> Le 13 nov. 2017 à 21:01, Stephane Ducasse  a écrit :
> 
> Hi guys
> 
> we are working on pillar and we will probably release a new alph version soon.
> I'm updating the doc. But I found that the doc I was writing can help
> some of you.
> 
> Julien is written a nice booklet on USBdrivers and he told me that
> this doc works super well on mac.
> 
> Stef
> 

Thanks for your work on this beautiful project guys. :-)

Julien

Re: [Pharo-users] Why is compile: breaking my image?

[Guillermo Polito]

Can you share what was the original problem and how you fixed it?

On Sat, Nov 11, 2017 at 4:44 PM, Sven Van Caekenberghe  wrote:

>
>
> > On 11 Nov 2017, at 16:33, Peter Uhnák  wrote:
> >
> > Never mind... I see now what is broken and I'll try to fix it (assuming
> my P7 image won't corrupt itself due to FreeType before I manage to push
> the changes... heh)
>
> You can now disable FreeType fonts and still use bitmapped Source Code
> fonts.
>
> > On Sat, Nov 11, 2017 at 3:43 PM, Peter Uhnák  wrote:
> > This applies to P61 (for some time) and P7.
> >
> > Object compile: '^'.
> >
> > Syntax Error popup -> close
> >
> > now you have two morphic UI processes running and World starts to get
> corrupted with artifacts around. (and it also in one case manage to
> actually corrupt the image to the point that I was no longer able to even
> launch it).
> >
> > Peter
> >
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Peeking at a stream

[Guillermo Polito]

Yeah, I understand. The thing is that we will remove in the near
future MultiByteFileStream.
And not all streams have conceptually a position. Today there was a mail
from Sven about that.

On Mon, Nov 13, 2017 at 2:48 PM, Prof. Andrew P. Black 
wrote:

>
> > On 2 Nov 2017, at 10:10 , Guillermo Polito 
> wrote:
> >
> > My first hunch is that you don't want to change PositionableStream.
> Because it works on collections and files (because of inheritance). But not
> on other kind of streams that are not part of the hierarchy, such as
> sockets. And we are cleaning that part.
> >
> > Instead, some time ago Sven produced a really nice hierarchy of stream
> decorators. Check the package:
> >
> > Zinc-Character-Encoding-Core
> >
> > There you have
> >
> > ZnBufferedReadStream
> >
> > That implements buffering in an orthogonal way. Maybe it makes more
> sense to put such method there?
> >
>
> I wanted this to be something light-weight.  I really don’t want to have
> to wrap my stream in a decorator before peeking ahead.
>
> Because I’m doing this in SmaCC, I implemented #explore: (that’s the name
> I chose) in SmaCCLineNumberStream.   But I think that the general solution
> is to put this method in a Trait, so that it can be combined into any
> stream, whether or not that stream inherits from PositionableStream.  There
> are probably other methods that could go in such a trait too.
>
> Actually, the idea of resetting a stream to a prior position is much less
> general, and easier to implement, then general positionability.  Over the
> weekend I posted an issue that discusses positioning a MultiButeFileStream
> — that’s a good example.
>
> Here is my implementation — really simple.
>
> ```
> explore: aBlock
> "evaluate aBlock with this stream as argument.  When done, reset
> my position to the current position."
>
> | savedPosition |
> savedPosition := self position.
> [ ^ aBlock value: self ] ensure: [ self position: savedPosition ]
> ```
>
> Andrew
>
>
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Stream API

[Guillermo Polito]

Thanks Sven, we should take that list of selectors and make a document or
Lint rules on them.

On Mon, Nov 13, 2017 at 9:08 PM, Stephane Ducasse 
wrote:

> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 
> wrote:
> > The idea is to have much simpler streams which can be composed to get
> more sophisticated behaviour.
> >
> > The most primitive streams should be binary read or write streams, like
> a raw file or network connection.
> >
> > To add a character encoding/decoding you wrap them in a
> ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer,
> cleaner ZnCharacterEncoders).
>
> Yes really nice :)
>
> And Guille started to use them and we are slowly rewriting all the
> stream internal users to use Zn and after we will be free.
>
>
> > If you want buffering, you wrap a ZnBufferedReadStream or
> ZnBufferedWriteStream around them.
> >
> > And there are some other examples in the system too.
> >
> > Have a look at BinaryFileStream and ZdcSocketStream.
> >
> > Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must
> die, because they try to be everything at once and are impossible to change.
>
>
> YES YES YES and celebrate. I could never understand anything. My brain
> is too limited for these kind of games :)
>
>
>
> > The contract of a stream should be much, much simpler than it is today.
>
> Fully agree.
>
> >
> > For writing that means
> >
> > #nextPut:
> > #nextPutAll:
> > #next:putAll:
> > #next:putAll:startingAt:
> >
> > the 3 last ones can be written in terms of of the first one, but the
> last one is key because it can be the most efficient.
> > And maybe also
> >
> > #flush
> > #close
> >
> > Some helpers for character writing are
> >
> > #space
> > #tab
> > #cr
> > #crlf
> > #lf
> >
> > Maybe #newline
>
> :)
>
>
> >
> > #<< is a handy method too.
> >
> > For reading that means
> >
> > #atEnd
> > #next
> > #next:
> > #next:into:
> > #next:into:startingAt:
> > #nextInto:
> > #peek
> > #skip:
> > #upToEnd
> > #upTo:
> > #readInto:startingAt:count:
> >
> > Again, they can all be written in terms of #next, but
> #readInto:startingAt:count: is the core, efficient one.
> > Note that #peek allows a one character lookahead, which should be
> sufficient for almost all parsing needs.
> >
> > #close is also a necessary operation, #peekFor: a handy one, #nextLine
> is popular too.
> >
> > There is a discussion about positioning (#position , #position: and
> related) but these cannot be supported _in general_ by the kind of streams
> described above.
> >
> > If you absolutely need these, read #upToEnd and use a regular ReadStream
> (over a fixed collection).
> >
> > The collection based classic Streams should always remain in the system,
> they are too handy. But have you seen for example, #nextInt32 on
> PositionableStream ? Good luck with that when the the underlying collection
> is anything other than bytes.
> >
> > All this being said, there is no one, single correct answer.
> >
> > But if we all try to simplify what we expect of streams (use a more
> limited API), we'll be more nimble to make implementation changes later on.
> >
> > Sven
> >
> >> On 13 Nov 2017, at 19:58, Stephane Ducasse 
> wrote:
> >>
> >> Hi Evan
> >>
> >> I think that we will use the ZnStreams.
> >> If we use Xtreams we will transform their API because some messages
> >> are not really good.
> >> Stef
> >>
> >> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue 
> wrote:
> >>> I've heard mention once or twice on this list and in some release
> notes of
> >>> what sounded like possible coming changes to the stream API. Could
> anyone
> >>> point me to any concrete details about that? I haven't been able to dig
> >>> anything up myself by searching. I'm about to write something that I'd
> like
> >>> to be polymorphic with the stream API, but if that's about to change,
> I'd
> >>> like to plan ahead.
> >>>
> >>> Thanks,
> >>> Evan
> >>
> >
> >
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] NeoJSON. Allowing null or an object

[Juraj Kubelka]

Hi Sven,

thank you for the fix! 

I understand that #allowNil is about reading, while #writeNil: is about 
writing. 
I use the same mapping for the reader and writer. This is why I spotted the 
case.

Thanks!
Juraj

> On Nov 13, 2017, at 16:30, Sven Van Caekenberghe  wrote:
> 
> Juraj,
> 
> Check out:
> 
> ===
> Name: Neo-JSON-Core-SvenVanCaekenberghe.46
> Author: SvenVanCaekenberghe
> Time: 13 November 2017, 6:59:13.995868 pm
> UUID: f412799a-431a-0d00-850e-5c3c05ce5378
> Ancestors: Neo-JSON-Core-SvenVanCaekenberghe.45
> 
> Fix the NeoJSONWriter>>#writeNil: true option by adding a short circuit to 
> NeoJSONWriter>>nextPut:as: (as reported by Juraj Kubelka)
> 
> Add #testRectanglePointsWithNil
> ===
> Name: Neo-JSON-Tests-SvenVanCaekenberghe.44
> Author: SvenVanCaekenberghe
> Time: 13 November 2017, 6:59:37.365898 pm
> UUID: 35acdd9b-431a-0d00-850f-878405ce5378
> Ancestors: Neo-JSON-Tests-SvenVanCaekenberghe.43
> 
> Fix the NeoJSONWriter>>#writeNil: true option by adding a short circuit to 
> NeoJSONWriter>>nextPut:as: (as reported by Juraj Kubelka)
> 
> Add #testRectanglePointsWithNil
> ===
> 
> These should fix your last case. I used your example in the new unit test.
> 
> Note that #allowNil on a mapper is about reading, not writing.
> 
> HTH,
> 
> Sven
> 
>> On 13 Nov 2017, at 17:10, Juraj Kubelka  wrote:
>> 
>> Hi, 
>> 
>> I have just found the answer for the reader:
>> 
>> -=-=-=-
>> rectangleJson := '{
>>  "origin" : null,
>>  "corner" : null
>> }'.
>> 
>> (NeoJSONReader on: rectangleJson readStream)
>>  mapInstVarsFor: Point;
>>  for: Point do: [ :mapping | 
>>  mapping allowNil ];
>>  for: Rectangle do: [ :mapping | 
>> (mapping mapInstVar: #origin) valueSchema: Point.
>> (mapping mapInstVar: #corner) valueSchema: Point ];
>>  nextAs: Rectangle.
>> -=-=-=-
>> 
>> I have an impression that there is a bug in the writer. While the following 
>> example works: 
>> 
>> -=-=-=-
>> String streamContents: [ :stream |
>>   (NeoJSONWriter on: stream)
>>  for: Point do: [ :mapping | 
>>  mapping mapAllInstVars.
>>  mapping allowNil ];
>> for: Rectangle do: [ :mapping | 
>>  (mapping mapInstVar: #origin) valueSchema: Point.
>>  (mapping mapInstVar: #corner) valueSchema: Point ];
>>  nextPut: Rectangle new ].
>> -=-=-=-
>> 
>> the following example does not work: 
>> 
>> -=-=-=-
>> String streamContents: [ :stream |
>>   (NeoJSONWriter on: stream)
>>  for: Point do: [ :mapping | 
>>  mapping mapAllInstVars.
>>  mapping allowNil ];
>> for: Rectangle do: [ :mapping | 
>>  (mapping mapInstVar: #origin) valueSchema: Point.
>>  (mapping mapInstVar: #corner) valueSchema: Point ];
>>  writeNil: true;
>>  nextPut: Rectangle new ].
>> -=-=-=-
>> 
>> What do you think?
>> Juraj
>> 
>>> On Nov 13, 2017, at 12:50, Juraj Kubelka  wrote:
>>> 
>>> Hi,
>>> 
>>> Please, how should I modify the mapping to be able to parse the following 
>>> example?
>>> 
>>> -=-=-=-
>>> rectangleJson := '{
>>>  "origin" : null,
>>>  "corner" : null
>>> }'.
>>> 
>>> (NeoJSONReader on: rectangleJson readStream)
>>>  mapInstVarsFor: Point;
>>>  for: Rectangle do: [ :mapping | 
>>> (mapping mapInstVar: #origin) valueSchema: Point.
>>> (mapping mapInstVar: #corner) valueSchema: Point ];
>>>  nextAs: Rectangle.
>>> -=-=-=-
>>> 
>>> I receive from a server JSON messages including null values. 
>>> Can we say use Point value schema or null? How? 
>>> 
>>> In the documentation I can see the example: 
>>> 
>>> -=-=-=-
>>> String streamContents: [ :stream |
>>>  (NeoJSONWriter on: stream)
>>> mapAllInstVarsFor: Point;
>>> writeNil: true;
>>> nextPut: Point new ].
>>> -=-=-=-
>>> that produces {"x":null,"y":null}
>>> 
>>> But I do not see how to apply this for the following example: 
>>> -=-=-=-
>>> String streamContents: [ :stream |
>>>  (NeoJSONWriter on: stream)
>>> mapAllInstVarsFor: Point;
>>>for: Rectangle do: [ :mapping | 
>>>  (mapping mapInstVar: #origin) valueSchema: Point.
>>>  (mapping mapInstVar: #corner) valueSchema: Point ];
>>> writeNil: true;
>>> nextPut: Rectangle new ].
>>> -=-=-=-
>>> 
>>> Thanks,
>>> Juraj
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-users] Stream API

[Stephane Ducasse]

On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe  wrote:
> The idea is to have much simpler streams which can be composed to get more 
> sophisticated behaviour.
>
> The most primitive streams should be binary read or write streams, like a raw 
> file or network connection.
>
> To add a character encoding/decoding you wrap them in a ZnCharacterReadStream 
> or ZnCharacterWriteStream (these use the newer, cleaner ZnCharacterEncoders).

Yes really nice :)

And Guille started to use them and we are slowly rewriting all the
stream internal users to use Zn and after we will be free.


> If you want buffering, you wrap a ZnBufferedReadStream or 
> ZnBufferedWriteStream around them.
>
> And there are some other examples in the system too.
>
> Have a look at BinaryFileStream and ZdcSocketStream.
>
> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, 
> because they try to be everything at once and are impossible to change.


YES YES YES and celebrate. I could never understand anything. My brain
is too limited for these kind of games :)



> The contract of a stream should be much, much simpler than it is today.

Fully agree.

>
> For writing that means
>
> #nextPut:
> #nextPutAll:
> #next:putAll:
> #next:putAll:startingAt:
>
> the 3 last ones can be written in terms of of the first one, but the last one 
> is key because it can be the most efficient.
> And maybe also
>
> #flush
> #close
>
> Some helpers for character writing are
>
> #space
> #tab
> #cr
> #crlf
> #lf
>
> Maybe #newline

:)


>
> #<< is a handy method too.
>
> For reading that means
>
> #atEnd
> #next
> #next:
> #next:into:
> #next:into:startingAt:
> #nextInto:
> #peek
> #skip:
> #upToEnd
> #upTo:
> #readInto:startingAt:count:
>
> Again, they can all be written in terms of #next, but 
> #readInto:startingAt:count: is the core, efficient one.
> Note that #peek allows a one character lookahead, which should be sufficient 
> for almost all parsing needs.
>
> #close is also a necessary operation, #peekFor: a handy one, #nextLine is 
> popular too.
>
> There is a discussion about positioning (#position , #position: and related) 
> but these cannot be supported _in general_ by the kind of streams described 
> above.
>
> If you absolutely need these, read #upToEnd and use a regular ReadStream 
> (over a fixed collection).
>
> The collection based classic Streams should always remain in the system, they 
> are too handy. But have you seen for example, #nextInt32 on 
> PositionableStream ? Good luck with that when the the underlying collection 
> is anything other than bytes.
>
> All this being said, there is no one, single correct answer.
>
> But if we all try to simplify what we expect of streams (use a more limited 
> API), we'll be more nimble to make implementation changes later on.
>
> Sven
>
>> On 13 Nov 2017, at 19:58, Stephane Ducasse  wrote:
>>
>> Hi Evan
>>
>> I think that we will use the ZnStreams.
>> If we use Xtreams we will transform their API because some messages
>> are not really good.
>> Stef
>>
>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue  wrote:
>>> I've heard mention once or twice on this list and in some release notes of
>>> what sounded like possible coming changes to the stream API. Could anyone
>>> point me to any concrete details about that? I haven't been able to dig
>>> anything up myself by searching. I'm about to write something that I'd like
>>> to be polymorphic with the stream API, but if that's about to change, I'd
>>> like to plan ahead.
>>>
>>> Thanks,
>>> Evan
>>
>
>

[Pharo-users] Thriving on chaos

[Stephan Eggermont]

Op 13-11-2017 om 02:55 schreef Викентий Потапов:

I'm very lazy and i like to read rich manuals more than to
investigate complex code. I think it is much more natural when you
don't need to study the whole system before you can do simple things.


The "thriving on chaos" kind of development with fast change we do in 
Pharo is not likely to develop many artifacts like that. The parts that 
stabilize develop them, and the ones that are in flux don't.


An issue might be that Pharo is slightly different in so many ways, and 
you are confronted with much more change than you are used to with VW. 
It takes time to adapt to a situation where continuous learning is 
needed and wanted, and the time where VW changed so fast is long over.



For example, i don't want to waste lots of time to understand what is
the difference between bloc and spec, i want to read few paragraphs
of manual and look into some class comments, and than do the task. So
i think you made a great progress in this direction with Spec - the
manual is very clear and allows developing UI with minimal efforts -
just to read some abstracts from manual.


Another difference is that in Pharo the development is transparent, you 
see all the new ideas and prototypes, good and bad. That is totally 
different from closed source development, where you only get a chance to 
react to things that are more or less finished. On the one hand that 
means you waste time on things that turn out to be bad ideas, on the 
other hand you have actual influence on how Pharo develops.



But in some areas i need to ask somebody who knows much more than i
do. And i don't think there could be "dumb questions",  but a
_lack_of_information_. Also, when something is evident to one - it
could be not so evident to another person. That is why i ask such
simple things.


There is no assumption of dumb questions. We assume we fail to document 
well enough. The questions were good enough and for some parts our 
answers are not yet good enough. We improve and continue to improve.
The way we are now able to quickly create booklets about a subject is 
much better than what we did before.



Also i became accustomed to the situation when platform implements
some basic stuff like i wrote earlier (UI tools, i18n, deployment,
etc) and it was not evident to me that such modern system as Pharo
cannot do it, so i asked about it.


One of our fallacies is wanting to do things better than existing 
systems. That sometimes results in parts that are in development for too 
long, and having to live with parts that are not finished. Also, open 
source frameworks are often only finished to the level needed for the 
original author's application.



I have seen that Pharo is powerful system but i need to decide what
to do: 1) create some personal solution based on different answers
above. Lots of code investigations, coding and debugging (fixing
existed bugs that are not on pharo roadmap).


I find the Pharo community is open to fixing bugs and answering 
questions. Open source definitely has the property that you are much 
more likely to get help if you show that you have tried to find a 
solution. Being less close to a large concentration of Pharo developers 
I've found it very useful to show what I have been playing with and 
where I'm running into.



2) wait until some
release of Pharo fix bugs with non-latin paths, implement minimal
level of integrated with UI framework i18n and deployment\packaging
of applications.


Pharo is improving  at a speed with which I'm certain that will happen. 
It will be sooner if you make Pharo yours, and help us get there.


Stephan

Re: [Pharo-users] PharoLauncher directories

[Stephan Eggermont]

Op 8-11-2017 om 15:56 schreef stephan:
I run into all kinds of issues with the directory structure used by the 
new PharoLauncher.


When I copy an image with the launcher, how can I synchronize the 
Iceberg repositories again? Do I just need to copy the original 
directory containing them? Is that something we want to automate?


Stephan

Re: [Pharo-users] Stream API

[Andrew Glynn]

Xtreams has very good performance, but the API’s are messy. I haven’t compared 
the performance of ZnStreams, but it shouldn’t be radically different.

From: Stephane Ducasse
Sent: Monday, November 13, 2017 1:59 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Stream API

Hi Evan

I think that we will use the ZnStreams.
If we use Xtreams we will transform their API because some messages
are not really good.
Stef

On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue  wrote:
> I've heard mention once or twice on this list and in some release notes of
> what sounded like possible coming changes to the stream API. Could anyone
> point me to any concrete details about that? I haven't been able to dig
> anything up myself by searching. I'm about to write something that I'd like
> to be polymorphic with the stream API, but if that's about to change, I'd
> like to plan ahead.
>
> Thanks,
> Evan

Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 102

[Stephane Ducasse]

On Mon, Nov 13, 2017 at 2:55 AM, Викентий Потапов
 wrote:
>
> Thanks Stef, also thank all of you for your support. It is very important to 
> me and shows that Pharo is really in progress.
> I didn't ever complained - i just asked simple questions on topics i don't 
> know. And i get lot's of answers to make some decisions. I understand where 
> to get information and what are the prospects of using Pharo.
>
> I came to Pharo looking for appropreate Smalltalk implementation after Cincom 
> denied access to its PUL version of VW. I found Pharo as the most advanced 
> but it also has its disadvantages.
>
> My project is a desktop GUI application with some hacks with saving data 
> to\from image on-the-fly and lots of GUI dialogs + complex custom GUI 
> control. It is a kind of personal data\information manager.


Did you look at the Spec book?



>
> I'm very lazy and i like to read rich manuals more than to investigate 
> complex code.

Me too. But nobody gets paid to write documentation not even me.


I think it is much more natural when you don't need to study the whole
system before you can do simple things. For example, i don't want to
waste lots of time to understand what is the difference between bloc
and spec, i want to read few paragraphs of manual and look into some
class comments, and than do the task.

> Bloc is not for you.

So i think you made a great progress in this direction with Spec - the
manual is very clear and allows developing UI with minimal efforts -
just to read some abstracts from manual.


> You see we wrote this manual for FREE.
I will also update it for FREE.



>
> But in some areas i need to ask somebody who knows much more than i do. And i 
> don't think there could be "dumb questions",  but a _lack_of_information_. 
> Also, when something is evident to one - it could be not so evident to 
> another person. That is why i ask such simple things.
>

There is no problem.
Just think that Pharo is open source and that it is our COMMON GOODS.
We all share it and we ALL try to make it better.





> Also i became accustomed to the situation when platform implements some basic 
> stuff like i wrote earlier (UI tools, i18n, deployment, etc) and it was not 
> evident to me that such modern system as Pharo cannot do it, so i asked about 
> it.


Sure now you can improve Pharo too.



> I have seen that Pharo is powerful system but i need to decide what to do:
> 1) create some personal solution based on different answers above. Lots of 
> code investigations, coding and debugging (fixing existed bugs that are not 
> on pharo roadmap).

If you have many forms you may have a look at magritte the Morph
builder does not work anymore but may be it is
worth fixing it.


> 2) wait until some release of Pharo fix bugs with non-latin paths, implement 
> minimal level of integrated with UI framework i18n and deployment\packaging 
> of applications.


It does not work like that.
If you do not open a bug entry with a clear problem description why
people not having this problem should fix it?

We are making sure that Pharo can be used for people to deliver
product and make money but
we have also our agenda and duties. Now the best things that you can
do is help yourself and we will help you
but do not expect that magically we fix the problems you have.
Look for example Alistair spotted some problems in FileSystem and he
fixed them and we integrated them
for the benefits of EVERYBODY.


>
> Every software developer tries to find the simplest solution for his task.

Yes but this is not the point. Pharo can shape your future and Pharo
is not a close product.
Now we can all contribute. Just start to open a bug entry with a test.
This is the first step if you want that we spend time on your problem.


>
> I apologized if i said something wrong, i really didn't want to hurt 
> somebody's feelings.

No do not worry. I have a strong skin :)


Stef

>
> Vikenti.
>
>>
>> We are focused on deployment but not the same way.
>> We are the first system that bootstrap a core and can load
>> dependencies on this core.
>> We have a dependency analyser that is really advanced since it can
>> check that you have message that are not in extension
>> of packages that you use.
>> In January I hope that we will start packaging Applications (versus
>> packaging code), so that people can deploy
>> desktop applications more easily.
>>
>> Now if people like vikenti wants our support. They should learn how to
>> engage a discussion with us and not
>> just complain :)
>>
>> Stef
>>
>

Re: [Pharo-users] FileReference>>#moveTo: across filesystems

[Stephane Ducasse]

This is great to see FileSystem improving.

On Mon, Nov 13, 2017 at 7:11 PM, Alistair Grant  wrote:
> Hi Claudio,
>
> On 13 November 2017 at 18:49, Claudio Corrodi  wrote:
>> Hi all,
>>
>> Manuel Leuenberger and I ran into an issue with the FileReference>>#moveTo:
>> method last week. On my system, I have "/" and "/home" in two different
>> partitions/file systems. If I do something like the following, Pharo
>> complains with a PrimitiveFailed signal:
>>
>> '/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt'
>> asFileReference
>>
>> I do not know how this is implemented exactly, but assume that the "rename"
>> syscall is used (on Linux systems, that is), which does not work across file
>> systems. The issue does not arise if I moveTo: inside the same filesystem.
>>
>> Is this expected behaviour? It is not obvious (to me) that
>> FileReference>>#moveTo: requires source and target to be on the same
>> filesystem. It would therefore make more sense to me if there were a
>> fallback that copies and deletes if two filesystems are involved (much like
>> "mv" behaves).
>>
>> What do you think?
>>
>> Cheers,
>> Claudio
>
> This issue was fixed some time ago.  I'm having trouble finding the
> fogbugz issue, but it is definitely fixed in Pharo 7.  Would you
> please let me know which build of Pharo you are using, and take a look
> at FileSystem>>move:to: and compare it to (minus the formatting
> changes :-)):
>
> move: sourcePath to: destination
> "Move the file /directory referenced as sourcePath to the destination
> referred as destPath.
> If there is no file at sourcePath, raise FileDoesNotExist.
> If destPath is a file, raise FileExists.
> If destPath is a directory, move the sourcePath in to the directory"
>
> | fullDestination |
>
> destination isFile ifTrue: [ FileExists signalWith: destination ].
> destination isDirectory
> ifTrue: [ fullDestination := destination / sourcePath basename ]
> ifFalse: [ fullDestination := destination ].
> self = destination fileSystem ifTrue:
> [
> "Ideally we would test whether the source and destination are on the
> same filesystem from the OSs perspective.
> Since we can't do that, just try rename, and if that fails, copy and delete."
> [ self rename: sourcePath to: fullDestination resolve path ]
> on: Error
> do: [ :error | self copyAndDelete: sourcePath to: fullDestination ].
> ] ifFalse:
> [ self copyAndDelete: sourcePath to: fullDestination ].
> ^fullDestination
>
>
> Cheers,
> Alistair
>

[Pharo-users] Stream API

[Evan Donahue]

I've heard mention once or twice on this list and in some release notes of
what sounded like possible coming changes to the stream API. Could anyone
point me to any concrete details about that? I haven't been able to dig
anything up myself by searching. I'm about to write something that I'd like
to be polymorphic with the stream API, but if that's about to change, I'd
like to plan ahead.

Thanks,
Evan

Re: [Pharo-users] FileReference>>#moveTo: across filesystems

[Alistair Grant]

Hi Claudio,

On 13 November 2017 at 18:49, Claudio Corrodi  wrote:
> Hi all,
>
> Manuel Leuenberger and I ran into an issue with the FileReference>>#moveTo:
> method last week. On my system, I have "/" and "/home" in two different
> partitions/file systems. If I do something like the following, Pharo
> complains with a PrimitiveFailed signal:
>
> '/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt'
> asFileReference
>
> I do not know how this is implemented exactly, but assume that the "rename"
> syscall is used (on Linux systems, that is), which does not work across file
> systems. The issue does not arise if I moveTo: inside the same filesystem.
>
> Is this expected behaviour? It is not obvious (to me) that
> FileReference>>#moveTo: requires source and target to be on the same
> filesystem. It would therefore make more sense to me if there were a
> fallback that copies and deletes if two filesystems are involved (much like
> "mv" behaves).
>
> What do you think?
>
> Cheers,
> Claudio

This issue was fixed some time ago.  I'm having trouble finding the
fogbugz issue, but it is definitely fixed in Pharo 7.  Would you
please let me know which build of Pharo you are using, and take a look
at FileSystem>>move:to: and compare it to (minus the formatting
changes :-)):

move: sourcePath to: destination
"Move the file /directory referenced as sourcePath to the destination
referred as destPath.
If there is no file at sourcePath, raise FileDoesNotExist.
If destPath is a file, raise FileExists.
If destPath is a directory, move the sourcePath in to the directory"

| fullDestination |

destination isFile ifTrue: [ FileExists signalWith: destination ].
destination isDirectory
ifTrue: [ fullDestination := destination / sourcePath basename ]
ifFalse: [ fullDestination := destination ].
self = destination fileSystem ifTrue:
[
"Ideally we would test whether the source and destination are on the
same filesystem from the OSs perspective.
Since we can't do that, just try rename, and if that fails, copy and delete."
[ self rename: sourcePath to: fullDestination resolve path ]
on: Error
do: [ :error | self copyAndDelete: sourcePath to: fullDestination ].
] ifFalse:
[ self copyAndDelete: sourcePath to: fullDestination ].
^fullDestination


Cheers,
Alistair

[Pharo-users] FileReference>>#moveTo: across filesystems

[Claudio Corrodi]

Hi all,

Manuel Leuenberger and I ran into an issue with the 
FileReference>>#moveTo: method last week. On my system, I have "/" and 
"/home" in two different partitions/file systems. If I do something like 
the following, Pharo complains with a PrimitiveFailed signal:


'/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt' 
asFileReference


I do not know how this is implemented exactly, but assume that the 
"rename" syscall is used (on Linux systems, that is), which does not 
work across file systems. The issue does not arise if I moveTo: inside 
the same filesystem.


Is this expected behaviour? It is not obvious (to me) that 
FileReference>>#moveTo: requires source and target to be on the same 
filesystem. It would therefore make more sense to me if there were a 
fallback that copies and deletes if two filesystems are involved (much 
like "mv" behaves).


What do you think?

Cheers,
Claudio

Re: [Pharo-users] I18n in pharo

[Hilaire]

Ok, got it.


Le 12/11/2017 à 13:04, Stephane Ducasse a écrit :

Yes. Morph and Polymorph as well as Athens but Sparta offers a similar
API. So conversion should be easy.
And Bloc opens a lot of possibilities. Bloc is the result of around 4
years of effort understanding the domain
and comparing solutions.


--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Embedded PDF viewer?

[Offray Vladimir Luna Cárdenas]

On 13/11/17 06:59, Ben Coman wrote:
> "Live programming PDF documents" seems like a catchy meme that the
> broader community may find intriguing.  
>
> Really, I'm just curious about what might be possible and can only
> discover that by walking the way.

Certainly I would be interested in that catchy meme. Please keep us
updated and keep also the good work.

Thanks,

Offray

Re: [Pharo-users] Open Debugger, Save and Quit

[Sean P. DeNigris]

Tim Mackinnon wrote
> you can override this and Fuel out the debug context to a file

Thanks, Tim! I do know about that, but I was thinking/hoping that maybe
there was a way to keep the debug context alive without fueling out…



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Embedded PDF viewer?

[Sean P. DeNigris]

Ben Coman wrote
> I've wanted PDF rendering inside Pharo for *years* and finally got a
> sniff of a solid possibility - so I'm chasing it down.  It might not pan
> out like I imagine, but "Live programming PDF documents" seems like a
> catchy meme that the broader community may find intriguing.

Go, go, go!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] NeoJSON. Allowing null or an object

[Juraj Kubelka]

Hi, 

I have just found the answer for the reader:

-=-=-=-
rectangleJson := '{
  "origin" : null,
  "corner" : null
}'.

(NeoJSONReader on: rectangleJson readStream)
  mapInstVarsFor: Point;
  for: Point do: [ :mapping | 
mapping allowNil ];
  for: Rectangle do: [ :mapping | 
 (mapping mapInstVar: #origin) valueSchema: Point.
 (mapping mapInstVar: #corner) valueSchema: Point ];
  nextAs: Rectangle.
-=-=-=-

I have an impression that there is a bug in the writer. While the following 
example works: 

-=-=-=-
String streamContents: [ :stream |
   (NeoJSONWriter on: stream)
for: Point do: [ :mapping | 
mapping mapAllInstVars.
mapping allowNil ];
   for: Rectangle do: [ :mapping | 
(mapping mapInstVar: #origin) valueSchema: Point.
(mapping mapInstVar: #corner) valueSchema: Point ];
  nextPut: Rectangle new ].
-=-=-=-

the following example does not work: 

-=-=-=-
String streamContents: [ :stream |
   (NeoJSONWriter on: stream)
for: Point do: [ :mapping | 
mapping mapAllInstVars.
mapping allowNil ];
   for: Rectangle do: [ :mapping | 
(mapping mapInstVar: #origin) valueSchema: Point.
(mapping mapInstVar: #corner) valueSchema: Point ];
  writeNil: true;
  nextPut: Rectangle new ].
-=-=-=-

What do you think?
Juraj

> On Nov 13, 2017, at 12:50, Juraj Kubelka  wrote:
> 
> Hi,
> 
> Please, how should I modify the mapping to be able to parse the following 
> example?
> 
> -=-=-=-
> rectangleJson := '{
>   "origin" : null,
>   "corner" : null
> }'.
> 
> (NeoJSONReader on: rectangleJson readStream)
>   mapInstVarsFor: Point;
>   for: Rectangle do: [ :mapping | 
>  (mapping mapInstVar: #origin) valueSchema: Point.
>  (mapping mapInstVar: #corner) valueSchema: Point ];
>   nextAs: Rectangle.
> -=-=-=-
> 
> I receive from a server JSON messages including null values. 
> Can we say use Point value schema or null? How? 
> 
> In the documentation I can see the example: 
> 
> -=-=-=-
> String streamContents: [ :stream |
>   (NeoJSONWriter on: stream)
>  mapAllInstVarsFor: Point;
>  writeNil: true;
>  nextPut: Point new ].
> -=-=-=-
> that produces {"x":null,"y":null}
> 
> But I do not see how to apply this for the following example: 
> -=-=-=-
> String streamContents: [ :stream |
>   (NeoJSONWriter on: stream)
>  mapAllInstVarsFor: Point;
>  for: Rectangle do: [ :mapping | 
>(mapping mapInstVar: #origin) valueSchema: Point.
>(mapping mapInstVar: #corner) valueSchema: Point ];
>  writeNil: true;
>  nextPut: Rectangle new ].
> -=-=-=-
> 
> Thanks,
> Juraj
> 
> 

[Pharo-users] NeoJSON. Allowing null or an object

[Juraj Kubelka]

Hi,

Please, how should I modify the mapping to be able to parse the following 
example?

-=-=-=-
rectangleJson := '{
   "origin" : null,
   "corner" : null
}'.

(NeoJSONReader on: rectangleJson readStream)
   mapInstVarsFor: Point;
   for: Rectangle do: [ :mapping | 
  (mapping mapInstVar: #origin) valueSchema: Point.
  (mapping mapInstVar: #corner) valueSchema: Point ];
   nextAs: Rectangle.
-=-=-=-

I receive from a server JSON messages including null values. 
Can we say use Point value schema or null? How? 

In the documentation I can see the example: 

-=-=-=-
String streamContents: [ :stream |
   (NeoJSONWriter on: stream)
  mapAllInstVarsFor: Point;
  writeNil: true;
  nextPut: Point new ].
-=-=-=-
that produces {"x":null,"y":null}

But I do not see how to apply this for the following example: 
-=-=-=-
String streamContents: [ :stream |
   (NeoJSONWriter on: stream)
  mapAllInstVarsFor: Point;
   for: Rectangle do: [ :mapping | 
 (mapping mapInstVar: #origin) valueSchema: Point.
 (mapping mapInstVar: #corner) valueSchema: Point ];
  writeNil: true;
  nextPut: Rectangle new ].
-=-=-=-

Thanks,
Juraj

Re: [Pharo-users] Open Debugger, Save and Quit

[Sven Van Caekenberghe]

I do something similar, in my WAHtmlHaltAndErrorHandler subclass

fuelOutException: exception
| filename context |
filename := 't3-seaside-exception-{1}.fuel' format: { ZTimestamp now 
format: '20010203T160506' }.
context := exception signalerContext.
[ FuelOutStackDebugAction serializeTestFailureContext: context 
toFileNamed: filename ]
on: Error
do: [ ]

But like Tim says, it works via a .fuel file, it does not change the image 
state. You then open the .fuel file in a similar image.

> On 13 Nov 2017, at 15:48, Tim Mackinnon  wrote:
> 
> Hi Sean - not sure if this is exactly what you are after, but there is a 
> method in the debugger that is invoked when you need to debug, you can 
> override this and Fuel out the debug context to a file (or I guess even a 
> variable in the image if you are also saving the image when it gets an 
> error). When the the image relaunches in a headful state you could check if 
> that file exists (or variable is not null) and then open a debugger on the 
> Fueled back in state?
> 
> Mariano’s article gave me all of the hints for doing something like this for 
> PharoLamda - (although I am reading the file from S3 and then creating the 
> debugger in a different image) - but I could imagine you doing this for what 
> you want?
> 
> If you need specific code I can dig it out for you tonight.
> 
> Tim
> 
>> On 12 Nov 2017, at 23:15, Sean P. DeNigris  wrote:
>> 
>> Sean P. DeNigris wrote
>>> In a headless image, I'd like to do the following: if there's any error,
>>> arrange to have a debugger open on the next (headful) launch, and then
>>> save
>>> and quit. 
>> 
>> Bump :) I can't believe no one knows how to do this!
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
> 
> 

Re: [Pharo-users] Open Debugger, Save and Quit

[Tim Mackinnon]

Hi Sean - not sure if this is exactly what you are after, but there is a method 
in the debugger that is invoked when you need to debug, you can override this 
and Fuel out the debug context to a file (or I guess even a variable in the 
image if you are also saving the image when it gets an error). When the the 
image relaunches in a headful state you could check if that file exists (or 
variable is not null) and then open a debugger on the Fueled back in state?

Mariano’s article gave me all of the hints for doing something like this for 
PharoLamda - (although I am reading the file from S3 and then creating the 
debugger in a different image) - but I could imagine you doing this for what 
you want?

If you need specific code I can dig it out for you tonight.

Tim

> On 12 Nov 2017, at 23:15, Sean P. DeNigris  wrote:
> 
> Sean P. DeNigris wrote
>> In a headless image, I'd like to do the following: if there's any error,
>> arrange to have a debugger open on the next (headful) launch, and then
>> save
>> and quit. 
> 
> Bump :) I can't believe no one knows how to do this!
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] Peeking at a stream

[Prof. Andrew P. Black]

> On 2 Nov 2017, at 10:10 , Guillermo Polito  wrote:
> 
> My first hunch is that you don't want to change PositionableStream. Because 
> it works on collections and files (because of inheritance). But not on other 
> kind of streams that are not part of the hierarchy, such as sockets. And we 
> are cleaning that part.
> 
> Instead, some time ago Sven produced a really nice hierarchy of stream 
> decorators. Check the package:
> 
> Zinc-Character-Encoding-Core
> 
> There you have 
> 
> ZnBufferedReadStream
> 
> That implements buffering in an orthogonal way. Maybe it makes more sense to 
> put such method there?
> 

I wanted this to be something light-weight.  I really don’t want to have to 
wrap my stream in a decorator before peeking ahead.

Because I’m doing this in SmaCC, I implemented #explore: (that’s the name I 
chose) in SmaCCLineNumberStream.   But I think that the general solution is to 
put this method in a Trait, so that it can be combined into any stream, whether 
or not that stream inherits from PositionableStream.  There are probably other 
methods that could go in such a trait too.

Actually, the idea of resetting a stream to a prior position is much less 
general, and easier to implement, then general positionability.  Over the 
weekend I posted an issue that discusses positioning a MultiButeFileStream — 
that’s a good example.  

Here is my implementation — really simple.

```
explore: aBlock
"evaluate aBlock with this stream as argument.  When done, reset my 
position to the current position."

| savedPosition |
savedPosition := self position.
[ ^ aBlock value: self ] ensure: [ self position: savedPosition ]
```

Andrew

Re: [Pharo-users] Embedded PDF viewer?

[Ben Coman]

On Mon, Nov 13, 2017 at 6:03 PM, K K Subbu  wrote:

> On Monday 13 November 2017 09:50 AM, Ben Coman wrote:
>
>> I've managed to build PDFium into a shared library on Ubuntu 16.04.
>> (I'll announce a blog post on this later.)
>> Now I'm considering the best bitmap format to bring the rendered page
>> back into Pharo.
>>
>
> Have you considered importing PDFs as a sequence of compressed PNGs into
> Pharo? If you not interested in twiddling pixels in the imported PDFs,
> perhaps PNG may be sufficient. They take up lesser space and easier to move
> around or re-export.
>
> Regards .. Subbu
>

Yes, I've certainly considered it.  Pragmatically, in my electrical career
I deal with a lot of single page A3 PDF scans of schematic drawings, so
pre-converting to a bitmap format outside of Pharo wouldn't lose much.
 But I've wanted PDF rendering inside Pharo for *years* and finally got a
sniff of a solid possibility - so I'm chasing it down.  It might not pan
out like I imagine, but "Live programming PDF documents" seems like a
catchy meme that the broader community may find intriguing.

Really, I'm just curious about what might be possible and can only discover
that by walking the way.

cheers -ben

Re: [Pharo-users] Embedded PDF viewer?

[K K Subbu]

On Monday 13 November 2017 09:50 AM, Ben Coman wrote:
I've managed to build PDFium into a shared library on Ubuntu 16.04.  
(I'll announce a blog post on this later.)
Now I'm considering the best bitmap format to bring the rendered page 
back into Pharo.


Have you considered importing PDFs as a sequence of compressed PNGs into 
Pharo? If you not interested in twiddling pixels in the imported PDFs, 
perhaps PNG may be sufficient. They take up lesser space and easier to 
move around or re-export.


Regards .. Subbu