Re: [Pharo-dev] summary of "float & fraction equality bug"
Good summary. I must add to comparison and operations, I’d add encoding, where ASN.1 Reals MUST convert to Float before encoding with mantissa, exponent, etc. Here is another Fraction -> Float conversion. As well as ScaledDecimal -> Float conversion. Sent from ProtonMail Mobile On Fri, Nov 10, 2017 at 06:59, wrote: > I would like to summarize my perspective of what emerged from the discussions > in the "float & fraction equality bug" trail. The topic is all about mixed > operations when both Fractions and Floats are involved in the mix and can be > restated as the question of whether it is better to automagically convert the > Float to a Fraction or the Fraction to a Float before performing the > operation. AFAIK, Pharo currently implements a dual-conversion strategy: (1) > it applies Float->Fraction for comparison like =, <=, etc. (2) it applies > Fraction->Float for operations like +, *, etc. The reason for (1) is > preservation of = as an equivalence and of <= as a total ordering. This is an > important point for most Smalltalkers. The reason for (2), however, is > dictated by a supposedly better performance. While it is true that Floats > perform better than Fractions, I'm not sure that it makes a noticeable > difference in everyday uses. Further, the Fraction->Float conversion might > even cost more than the gain of using Floats for the real work, the operation > itself. The conversion Float->Fraction, on the contrary, is easier. But the > major disadvantage of (2) is that it enters the world of limited precision > computation (e.g., Floats), which is much harder to understand, less > intuitive, more surprising for most of us. So, it might be worthwhile to > suppress (2) and consistently apply Float->Fraction conversions whenever > needed. It won't make daily computations noticeably slower and helps in > preserving more enjoyable properties than the current dual-conversion regime. > Also, it won't prevent the numericists or other practitioners to do floating > point computations in mixed contexts: just apply explicit Fraction->Float > conversions when so desired. This will be at odd with other Smalltalk > implementations but might end up being a safer environment. I would like to > thank Nicolas in particular for being so quick in answering back and for the > good points he raised. Greetings Raffaello
Re: [Pharo-dev] float & fraction equality bug
To break down the ASN.1 encoding of 0.1 we have the following: sign * mantissa * (2 raisedTo: scalingFactor) * (base raisedTo: exponent). And in this case the values for 0.1 are as follows: self assert: sign = 1. self assert: mantissa = 3602879701896397. self assert: scalingFactor = 0. self assert: base = 2. self assert: exponent = -55. Just to close it up... - HH > Original Message > Subject: Re: [Pharo-dev] float & fraction equality bug > Local Time: November 9, 2017 10:13 AM > UTC Time: November 9, 2017 3:13 PM > From: he...@callistohouse.club > To: Pharo Development List > > ASN.1 encoding is a long standing encoding format and includes accepted > encoding of Reals and Integers. I read this thread and decided to see what > difference that ASN.1 Real encoding may report between this float and the > fraction. It turns out it is the same, but not in an equality test with the > fraction. That is due to conversion from Fraction to Float before encoding. > Here is the results I found: > > ASN1OutputStream encode: (1/10). > ASN1OutputStream encode: (0.1). > bytes := #[9 9 128 201 12 204 204 204 204 204 205] > > This breaks down as in: > ASN1InputStream decodeBytes: bytes. > obj := (3602879701896397/36028797018963968) > > Which equals 0.1, but does not equal (1/10). > > Food for thought regarding ASN.1 encoding of Reals. > > - HH > >> Original Message >> Subject: Re: [Pharo-dev] float & fraction equality bug >> Local Time: November 9, 2017 9:48 AM >> UTC Time: November 9, 2017 2:48 PM >> From: tu...@tudorgirba.com >> To: Pharo Development List >> >> Hi, >> >> Thanks for the answer. The example I provided was for convenience. >> >> I still do not understand why it is wrong to expect 0.1 = (1/10) to be true. >> >> Doru >> >>> On Nov 9, 2017, at 3:36 PM, Nicolas Cellier >>> nicolas.cellier.aka.n...@gmail.com wrote: >>> Nope, not a bug. >>> If you use Float, then you have to know that (x -y) isZero and (x = y) are >>> two different things. >>> Example; Float infinity >>> In your case you want to protect against (x-y) isZero, so just do that. >>> 2017-11-09 15:15 GMT+01:00 Tudor Girba tu...@tudorgirba.com: >>> Hi, >>> I just stumbled across this bug related to the equality between fraction >>> and float: >>> https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo >>> In essence, the problem can be seen that by doing this, you get a >>> ZeroDivide: >>> x := 0.1. >>> y := (1/10). >>> x = y ifFalse: [ 1 / (x - y) ] >>> The issue seems to come from the Float being turned to a Fraction, rather >>> than the Fraction being turned into a Float: >>> Fraction(Number)>>adaptToFloat: rcvr andCompare: selector >>> "If I am involved in comparison with a Float, convert rcvr to a >>> Fraction. This way, no bit is lost and comparison is exact." >>> rcvr isFinite >>> ifFalse: [ >>> selector == #= ifTrue: [^false]. >>> selector == #~= ifTrue: [^true]. >>> rcvr isNaN ifTrue: [^ false]. >>> (selector = #< or: [selector = #'<=']) >>> ifTrue: [^ rcvr positive not]. >>> (selector = #> or: [selector = #'>=']) >>> ifTrue: [^ rcvr positive]. >>> ^self error: 'unknow comparison selector']. >>> ^ rcvr asTrueFraction perform: selector with: self >>> Even if the comment says that the comparison is exact, to me this is a bug >>> because it seems to fail doing that. What do you think? >>> Cheers, >>> Doru >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> "Problem solving should be focused on describing >>> the problem in a way that makes the solution obvious." >> >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes."
Re: [Pharo-dev] float & fraction equality bug
ASN.1 encoding is a long standing encoding format and includes accepted encoding of Reals and Integers. I read this thread and decided to see what difference that ASN.1 Real encoding may report between this float and the fraction. It turns out it is the same, but not in an equality test with the fraction. That is due to conversion from Fraction to Float before encoding. Here is the results I found: ASN1OutputStream encode: (1/10). ASN1OutputStream encode: (0.1). bytes := #[9 9 128 201 12 204 204 204 204 204 205] This breaks down as in: ASN1InputStream decodeBytes: bytes. obj := (3602879701896397/36028797018963968) Which equals 0.1, but does not equal (1/10). Food for thought regarding ASN.1 encoding of Reals. - HH > Original Message > Subject: Re: [Pharo-dev] float & fraction equality bug > Local Time: November 9, 2017 9:48 AM > UTC Time: November 9, 2017 2:48 PM > From: tu...@tudorgirba.com > To: Pharo Development List > > Hi, > > Thanks for the answer. The example I provided was for convenience. > > I still do not understand why it is wrong to expect 0.1 = (1/10) to be true. > > Doru > >> On Nov 9, 2017, at 3:36 PM, Nicolas Cellier >> nicolas.cellier.aka.n...@gmail.com wrote: >> Nope, not a bug. >> If you use Float, then you have to know that (x -y) isZero and (x = y) are >> two different things. >> Example; Float infinity >> In your case you want to protect against (x-y) isZero, so just do that. >> 2017-11-09 15:15 GMT+01:00 Tudor Girba tu...@tudorgirba.com: >> Hi, >> I just stumbled across this bug related to the equality between fraction and >> float: >> https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo >> In essence, the problem can be seen that by doing this, you get a ZeroDivide: >> x := 0.1. >> y := (1/10). >> x = y ifFalse: [ 1 / (x - y) ] >> The issue seems to come from the Float being turned to a Fraction, rather >> than the Fraction being turned into a Float: >> Fraction(Number)>>adaptToFloat: rcvr andCompare: selector >> "If I am involved in comparison with a Float, convert rcvr to a >> Fraction. This way, no bit is lost and comparison is exact." >> rcvr isFinite >> ifFalse: [ >> selector == #= ifTrue: [^false]. >> selector == #~= ifTrue: [^true]. >> rcvr isNaN ifTrue: [^ false]. >> (selector = #< or: [selector = #'<=']) >> ifTrue: [^ rcvr positive not]. >> (selector = #> or: [selector = #'>=']) >> ifTrue: [^ rcvr positive]. >> ^self error: 'unknow comparison selector']. >> ^ rcvr asTrueFraction perform: selector with: self >> Even if the comment says that the comparison is exact, to me this is a bug >> because it seems to fail doing that. What do you think? >> Cheers, >> Doru >> -- >> www.tudorgirba.com >> www.feenk.com >> "Problem solving should be focused on describing >> the problem in a way that makes the solution obvious." > > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes."
Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win
This is the advantage of in-image SSL solution, found in the Cryptography repository: http://www.squeaksource.com/Cryptography.html Sent from ProtonMail Mobile On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti wrote: > Hi, the SqueakSSL dll is not included in the Pharo 64bit/Win vm distribution. > I guess this has to do with problems in building it. Anybody knows where the > difficulties lie? Greetings Raffaello
Re: [Pharo-dev] , for vector creation
I would note that 1 ! 2 creates/extends an ETuple in eLinda. - HH On Wed, Oct 25, 2017 at 16:53, Stephane Ducasse wrote: > In Polymath I guess that the vectors are longer. But if I'm correct it is #( > 12 23) asVector. Doru did you look at Jun because Jun introduced 3DPoint and > I wonder if they did not introduce Vector? What would be the alternatives for > vector? Any idea how this is done in other languages 1~>2 1!2 1-}2 Stef On > Wed, Oct 25, 2017 at 8:56 PM, Tudor Girba wrote: > Hi, > > Vector is not > Bloc-sepcific. We just need it in Bloc and because there wasn’t any, we now > have one in Bloc. But, it can be pulled out without any issues. > > Cheers, > > Doru > > >> On Oct 25, 2017, at 8:21 PM, Peter Uhnák wrote: >> >> For > example, in FileReference is adds a file extension. PetitParser uses it as a > sequence operator. >> >> But in both cases #, is sent to FileReference/Petit > parser instance, so it is contained. >> You would use it on a (generic) > Number and tie it to specific Bloc meaning. Maybe have a polymorphic Vector > in regular Pharo (I would imagine that PolyMath could also make use of that)? > >> >> Peter > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things > are difficult to teach." > > > > > @gmail.com> @tudorgirba.com>
Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations
Please excuse all the low-level detail, if inappropriate to the discussion. The
protocol changes are here specified.
- HH
On Tue, Oct 24, 2017 at 13:40, henry
<[he...@callistohouse.club]("mailto:he...@callistohouse.club";)> wrote:
> In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support,
> the frame header stays the same and the processing of the ProtocolOffered
> would select "ParrotTalk-3.6" to use the compact protocol of
>
> - ProtocolOffered { offered, preferred }
> - ProtocolAccepted { accepted }
> - IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols,
> dataEncoders }
> - IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder,
> dhParam }
> - Go { cryptoProtocol, dataEncoder, dhParam, signature }
> - GoToo { signature }
>
> Using eLinda :
>
> [http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz]("http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz";)
>
> Above the FrameBuffer, below the SessionOperations for each version of the
> protocol, an ELindaSession could be inserted. This session think would have
> the stacks for each protocol version SessionOperation registered by protocol
> in a Tuple, for eventual callback. When the ProtocolOffered comes in we
> publish the tuple frame, with set selected version, to route to the correct
> SessionOperation to support each version of the protocol.
>
> With a non-specific vatId required, anonymous connections would be supported.
>
> - HH
>
> On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse
> <[stepharo.s...@gmail.com](""mailto:stepharo.s...@gmail.com"";)> wrote:
>
>> Hi henry thanks for this announce. Can you tell where such protocols are
>> used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am
>> happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and
>> Pharo, found here: > >
>> http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows
>> this specification: >
>> https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf
>> > > One item of note, in version 3.5, the system connecting to a server,
>> sending > the IWant msg, must know the vatId of the system being connected
>> to. I am > considering changing this to version 3.6 by removing one
>> round-trip in > messaging. Therefore, these messages would be combined:
>> IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and
>> ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and
>> 3.6. > > Thoughts please? > > - HH @callistohouse.club>
Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations
In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the
frame header stays the same and the processing of the ProtocolOffered would
select "ParrotTalk-3.6" to use the compact protocol of
- ProtocolOffered { offered, preferred }
- ProtocolAccepted { accepted }
- IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols,
dataEncoders }
- IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder,
dhParam }
- Go { cryptoProtocol, dataEncoder, dhParam, signature }
- GoToo { signature }
Using eLinda :
http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz
Above the FrameBuffer, below the SessionOperations for each version of the
protocol, an ELindaSession could be inserted. This session think would have the
stacks for each protocol version SessionOperation registered by protocol in a
Tuple, for eventual callback. When the ProtocolOffered comes in we publish the
tuple frame, with set selected version, to route to the correct
SessionOperation to support each version of the protocol.
With a non-specific vatId required, anonymous connections would be supported.
- HH
On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse
<[stepharo.s...@gmail.com]("mailto:stepharo.s...@gmail.com";)> wrote:
> Hi henry thanks for this announce. Can you tell where such protocols are
> used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am
> happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and
> Pharo, found here: > >
> http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows
> this specification: >
> https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf
> > > One item of note, in version 3.5, the system connecting to a server,
> sending > the IWant msg, must know the vatId of the system being connected
> to. I am > considering changing this to version 3.6 by removing one
> round-trip in > messaging. Therefore, these messages would be combined:
> IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and
> ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and
> 3.6. > > Thoughts please? > > - HH @callistohouse.club>
Re: [Pharo-dev] latest Cryptography package integration
I am grateful for your interest.
The issue is conflicting requirements:
1 - same package for Squeak and Pharo.
2 - X509 support is spurious but RSA depends on ASN.1 support
3 - Pharo [and Squeak!] both have hash functions and DigitalSecureAlgorithm
that may get overwritten, leading to...
4 - Both Squeak and Pharo should have a common basis of crypto in both minimal
images.
5 - Bootstrap loads a separately repositoried [in SmalltalkHub] Cryptography
fork version 50, from version 36 common. Andso...
6 - we need a) common basic loaded, common support, b) common crypto-full
loadable by Squeak, Pharo [and Bootstrap!] and c) removal of Undeclared.
I think this sums up our situation. Would others be willing to commit to make
these basis changes, in both Squeak and Pharo?
Thank you,
Henry
On Tue, Oct 24, 2017 at 12:55, Stephane Ducasse
<[stepharo.s...@gmail.com]("mailto:stepharo.s...@gmail.com";)> wrote:
> I would like the package to be working for Pharo. Now from your description I
> have problem to really understand the situation. I think that Pharo core
> should have minimum and packages should be able to be loaded nicely on top. >
> Currently, SHA1, SHA256 and MD5 all get redefined by Cryptography-zzz.111.mcz
> loading. Do you mean that the version in Pharo are older than the one in 111?
> Stef On Tue, Oct 24, 2017 at 6:17 PM, henry wrote: > I am curious as to
> integration of the newest Cryptography package there into > Pharo. There are
> two Undeclared: SoundRecorder and FillInTheBlank, though I > do not know if
> such would be a part of a Pharo-Squeak compatibility layer. > > More
> pertinent would be what to do with the HashFunctions that already > reside in
> the Pharo image. If the decision was to include the entire > Cryptography
> into base, then making the HashFunctions not go Obselete would > be the
> objective. > > Currently, SHA1, SHA256 and MD5 all get redefined by >
> Cryptography-zzz.111.mcz loading. > > What do you think about bringing
> Cryptography up to date for Pharo and what > would be needed. It would help
> to seek common ground between Squeak and > Pharo, yes? > > > - HH > >
> @callistohouse.club>
Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations
In my tests, at the moment. Only there. I derived the ParrotTalk-3.5 spec from
eright’s.org’s ELib implementation.
Do you think I should change the spec to allow for free, anonymous connections?
- HH
On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse
<[stepharo.s...@gmail.com]("mailto:stepharo.s...@gmail.com";)> wrote:
> Hi henry thanks for this announce. Can you tell where such protocols are
> used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am
> happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and
> Pharo, found here: > >
> http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows
> this specification: >
> https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf
> > > One item of note, in version 3.5, the system connecting to a server,
> sending > the IWant msg, must know the vatId of the system being connected
> to. I am > considering changing this to version 3.6 by removing one
> round-trip in > messaging. Therefore, these messages would be combined:
> IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and
> ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and
> 3.6. > > Thoughts please? > > - HH @callistohouse.club>
Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations
Oh! I was U.N.familiar with Parrot drones. That’s awesome! Well how about using
encrypted communications with a Parrot drone? This is the purpose and
accomplishment of ParrotTalk, encrypted communications.
In 33 classes, minus 4 test classes with 16 tests (same #, 16, as eLinda!),
ParrotTalk delivers 2048-bit key negotiation to encrypt communications with
user-selected (through the SessionAgentMap - see tests) cryptoProtocol [AESede,
DESede, DES], as well as allowing user-selected encoding [asn1der, Bytes
{JSON}] of content data.
I am considering changing the spec to 3.6, as I mentioned.
- HH
On Tue, Oct 24, 2017 at 12:44, Alexandre Bergel
<[alexandre.ber...@me.com]("mailto:alexandre.ber...@me.com";)> wrote:
> Hi! What ParrotTalk is about? It does not seem related to the drone stuff
> (https://www.parrot.com) ? (Which I first thought). I had a look at the .pdf
> you’ve sent, it seems to do something with networking
> Cheers, Alexandre
>
>> On Oct 24, 2017, at 9:33 AM, henry wrote: > > Hi all, > > I am happy to
>> announce the release of version 3.5 of ParrotTalk, for Squeak and Pharo,
>> found here: > >
>> http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows
>> this specification: >
>> https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFrameDesign-3.5.pdf
>> > > One item of note, in version 3.5, the system connecting to a server,
>> sending the IWant msg, must know the vatId of the system being connected to.
>> I am considering changing this to version 3.6 by removing one round-trip in
>> messaging. Therefore, these messages would be combined: IWant/GiveInfo,
>> IAm/ReplyInfo. I will keep ProtocolOffered and ProtocolAccepted to allow
>> eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? >
>> > - HH @callistohouse.club>
[Pharo-dev] latest Cryptography package integration
I am curious as to integration of the newest Cryptography package there into Pharo. There are two Undeclared: SoundRecorder and FillInTheBlank, though I do not know if such would be a part of a Pharo-Squeak compatibility layer. More pertinent would be what to do with the HashFunctions that already reside in the Pharo image. If the decision was to include the entire Cryptography into base, then making the HashFunctions not go Obselete would be the objective. Currently, SHA1, SHA256 and MD5 all get redefined by Cryptography-zzz.111.mcz loading. What do you think about bringing Cryptography up to date for Pharo and what would be needed. It would help to seek common ground between Squeak and Pharo, yes? - HH
Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads
Hi Marcus,
Are you using SHA256 inside Pharo to generate the checksum files? If so were
you planning to use the OpenPGP by hmmosner, in the Cryptography repository for
PGP signatures?
I am curious as to integration of the newest Cryptography package there into
Pharo. There are two Undeclared: SoundRecorder and FillInTheBlank, though I do
not know if such would be a part of a Pharo-Squeak compatibility layer.
More pertinent would be what to do with the HashFunctions that already reside
in the Pharo image. If the decision was to include the entire Cryptography into
base, then making the HashFunctions not go Obselete would be the objective.
Currently, SHA1, SHA256 and MD5 all get redefined by Cryptography-zzz.111.mcz
loading.
What do you think about bringing Cryptography up to date for Pharo and what
would be needed. It would help to seek common ground between Squeak and Pharo,
yes?
HH
On Tue, Oct 24, 2017 at 11:34, Marcus Denker
<[marcus.den...@inria.fr]("mailto:marcus.den...@inria.fr";)> wrote:
> Hi,
>
> A tiny first step: I added sha256 chechsums for all downloads created by the
> Pharo6 build process
>
> [https://ci.inria.fr/pharo/]("https://ci.inria.fr/pharo/";)
>
> This step:
>
> [https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/]("https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/";)
>
> now creates .sha256.txt files, e.g for the mac:
>
> [https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt]("https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt";)
>
> This allows to check that downloads from the file server are indeed the same
> files that the build server created.
> [http://files.pharo.org/platform/]("http://files.pharo.org/platform/";)
> [http://files.pharo.org/image/60/]("http://files.pharo.org/image/60/";)
>
> As I said, just a very first step.
>
> TODO:
> - pgp signatures
> - insert into website
> - SSL for [files.pharo.org]("http://files.pharo.org";)
> - do it Pharo7
> - ….
>
> So: more to come!
>
> Marcus
Re: [Pharo-dev] Can we have subclasses of Process?
EventualProcess is in eventual_test [*], as example. Do not run RefsTest>>#testFailedArithmaticwithEventualArgument or will segfault vm. - HH [*] - http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz On Thu, Aug 17, 2017 at 08:33, Guillermo Polito wrote: > I think there is no technical limitation for it, AFAIK, the VM never checks > the class of a process. I also proposed something like that in this paper: > > http://guillep.github.io/files/publications/Poli14b-IWST-GlobalStateClassification.pdf > > On Thu, Aug 17, 2017 at 2:24 PM, Max Leske wrote: > >> I've used subclasses of process for the debugger stuff without problems. >> Max >> >> On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisi...@gmail.com) wrote: >> >>> Hi. >>> >>> Is it allowed to subclass Process? I remember that there were some >>> problems with it but I could not find any information. >>> >>> Generally I think about system processes which can be represented by >>> concrete subclasses. For example explicit UIProcess can be used to remove >>> many #isUIProcess conditions from system. >>> >>> Best regards, >>> Denis > > -- > > Guille Polito > > Research Engineer > > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13
Re: [Pharo-dev] eventual crashes pharo vm
That is good news, that it is due to this code doing funniness than a VM issue. This code trying to bring asynchrony within a synchronous environment brings new issues. What do you think that right solution is to the issue of a call expected to be immediate, change out to go eventual until the arguments resolve? How can it be structured correctly on the stack without generic functions? I think with the double dispatch of an eventual but I have not spend much time in this particular area. Preventing the vm from crashing would be a good interim step but even here I am not sure how to go about crafting a solution. Thank you for investigating this. - HH On Wed, Aug 16, 2017 at 20:46, Eliot Miranda wrote: > Hi Henry, Hi Marcus, > > On Sun, Aug 13, 2017 at 5:08 AM, henry wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the >> pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html >> >> - HH > > I took a look at this and I think you've found a bug in the > mustBeBooleanMagic: code. What's happening is a mustBeBoolean in Integer>>* > due to evaluating > 10 * 42 eventual > in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument > > Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does > ^super * anInteger (where anInteger is the NearERef). So that evaluates > Integer>>* > > Integer>>* aNumber > "Refer to the comment in Number * " > aNumber isInteger ifTrue: > [^ self digitMultiply: aNumber > neg: self negative ~~ aNumber negative]. > ^ aNumber adaptToInteger: self andSend: #* > > aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and > this provokes a mustBeBoolean for the isInteger ifTrue: [... > > After the mustBeBooleanMagic: the stack looks wrong. The activation of > Integer>>*, which is about to do > ^ aNumber adaptToInteger: self andSend: #* > does not have enough items on the stack. Instead of containing > a NearERef (for 42) > 10 > #* > it contains > a PromiseERef (for 42 eventual isInteger) > and the send of #adaptToInteger:andSend: ends up taking more form the stack > than the VM can handle and it crashes. The bug appears to be with the use of > sendNode irInstruction nextBytecodeOffsetAfterJump in > Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 > below, but does so at bytecode 57 > > 41 <10> pushTemp: 0 > 42 send: isInteger > 43 jumpFalse: 54 > 45 <70> self > 46 <10> pushTemp: 0 > 47 <70> self > 48 send: negative > 49 <10> pushTemp: 0 > 50 send: negative > 51 send: ~~ > 52 send: digitMultiply:neg: > 53 <7C> returnTop > 54 <10> pushTemp: 0 > 55 <70> self > 56 <24> pushConstant: #* > 57 send: adaptToInteger:andSend: > 58 <7C> returnTop > > So the positioning of the context's pc must be before any argument marshaling > for the next send, not simply the send itself. > > Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC > and resumePC temporaries at the beginning and capture them via > initialPC := context pc. > at the beginning and then > context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump) > to see what I'm seeing. > > Phew. Glad it's not a VM bug :-) > > HTH > _,,,^..^,,,_ > best, Eliot
Re: [Pharo-dev] @About posting here
- HH > Original Message > Subject: Re: [Pharo-dev] @About posting here > Local Time: August 16, 2017 7:40 AM > UTC Time: August 16, 2017 11:40 AM > From: norb...@hartl.name > To: Pharo Dev > >> Am 16.08.2017 um 13:21 schrieb Guillermo Polito : >> >> Hi Frank, >> >> I'll just repeat Stef's message: It's not about being straight or having >> unpopular opinions. It's about being rude and on the limit of the insult. I >> feel myself some harshness in your messages, it's like you're saying that >> everybody but you is stupid. I know that you did not say that "explicitly" >> but that's the way it feels. And I'm sure I'm not the only one feeling like >> it. >> >> Of course, that did not prevent me to answer you politely, but at the end >> what will happen is that people will not answer you anymore. Just take into >> account that if many people think already that your mails are aggressive, >> there may be some fault on your side too. >> >> That said, this does not mean that I want to "censor" you. Just choose >> better your words but keep the same content. > > +1 to all you said. > > And I would like to know why every smalltalk troll is german? That's so sad! I think it is a subset of trolls. Not just smalltalk trolls are German, all trolls are German. Same mentat, from any other LandStuhl, is properly a ghoul, not a troll. I personally think it is because Germans' are taught to never hold their tongue, after WW 1 and 2. I would ask you, have you ever seen a German holding their tonguie? So, I ramble on in hopes you are not so sad. > Norbert > >> On Wed, Aug 16, 2017 at 12:52 PM, Frank-B >> wrote: >> >>> Phil, >>> >>> nice attempt to drill and silence me! My advise: They all failed! >>> >>> If somebody can't cope with straight critics or unpopular opinions that aint >>> my fault. >>> >>> Frank >>> who never worried about being labeled and >>> from a country where free speech is still welcome >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p4961628.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - >> [http://www.cnrs.fr](http://www.cnrs.fr/) >> >> Web: [http://guillep.github.io](http://guillep.github.io/) >> Phone: +33 06 52 70 66 13
Re: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming Techniques and Reflection, Deadline August 20
I was thinking of possibly submitting, yet having never done so before, I find the amount of documentation learning just to submit in acceptable format has put me off. I just want to focus on building not talking about building. That that limits the degree of spread of my work, so be it. Thank you anyways, good luck with the conference, - HH > Original Message > Subject: [Pharo-dev] [CfP Deadline Extension] Workshop on Meta-Programming > Techniques and Reflection, Deadline August 20 > Local Time: August 16, 2017 5:08 AM > UTC Time: August 16, 2017 9:08 AM > From: smallt...@stefan-marr.de > To: Pharo Development List , The general-purpose > Squeak developers list > > Call for Papers: Meta’17 > > > Workshop on Meta-Programming Techniques and Reflection > > Co-located with SPLASH 2017 > October 22, 2017, Vancouver, Canada > > Twitter @MetaAtSPLASH > http://2017.splashcon.org/track/meta-2017 > > The heterogeneity of mobile computing, cloud applications, multicore > architectures, and other systems leads to increasing complexity of software > and > requires new approaches to programming languages and software engineering > tools. To manage the complexity, we require generic solutions that can be > adapted to specific application domains or use cases, making metaprogramming > an > important topic of research once more. However, the challenges with > metaprogramming are still manifold. They start with fundamental issues such as > typing of reflective programs, continue with practical concerns such as > performance and tooling, and reach into the empirical field to understand how > metaprogramming is used and how it affects software maintainability. Thus, > while industry accepted metaprogramming on a wide scale with Ruby, Scala, > JavaScript and others, academia still needs to answer a wide range of > questions > to bring it to the same level of convenience, tooling, and programming styles > to cope with the increasing complexity of software systems. > > This workshop aims to explore meta-level technologies that help tackling the > heterogeneity, scalability and openness requirements of emerging computations > platforms. > > ### Topics of Interest > > The workshop is a venue for all approaches that embrace metaprogramming: > > - from static to dynamic techniques > - reflection, meta-level architectures, staging, open language runtimes > applications to middleware, frameworks, and DSLs > - optimization techniques to minimize runtime overhead > - contract systems, or typing of reflective programs > reflection and metaobject protocols to enable tooling > - case studies and evaluation of such techniques, e.g., to build applications, > language extensions, or tools > - empirical evaluation of metaprogramming solutions > - security in reflective systems and capability-based designs > - meta-level architectures and reflective middleware for modern runtime > platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) > - surveys, conceptualization, and taxonomization of existing approaches > > In short, we invite contributions to the workshop on a wide range of topics > related to design, implementation, and application of reflective APIs and > meta-programming techniques, as well as empirical studies and typing for such > systems and languages. > > ### Workshop Format and Submissions > > This workshop welcomes the presentation of new ideas and emerging problems as > well as mature work as part of a mini-conference format. Furthermore, we plan > interactive brainstorming and demonstration sessions between the formal > presentations to enable an active exchange of ideas. Therefore, we seek the > following kinds of publications: > > • technical paper: max. 8 pages, excluding references > • position and work-in-progress paper: 1-4 pages, excluding references > • technology demos or a posters: 1-page abstract > > All papers are to be submitted using the SIGPLAN acmart style. Please use the > provided double-column Latex or Word templates. > > For the submission, please use the submission system at: > https://meta17.hotcrp.com/ > > The workshop technical papers will be published in the ACM DL, if not > requested otherwise by the authors. Thus, they will be part of SPLASH > workshop proceedings. Demos, posters, position and work-in-progress papers > can be submitted on a second, later deadline to discuss the latest results > and current work and won’t be included in the ACM DL proceedings. > > ### Important Dates > > Abstract Submission: 07 August 2017 > Paper Submission: 20 August 2017 > Author Notification: 06 September 2017 > Position/WIP Paper Deadline: 08 September 2017 > Camera Ready Deadline: 18 September 2017 > Position/WIP Notification: 21 September 2017 > > ### Program Committee > > The program committee consists of the organizers and the following reviewers: > > Anya Helen Bagge, University of Bergen, Norway > Daniele Bonetta, Oracle
Re: [Pharo-dev] [squeak-dev] Serializers/Encoders
To clarify, external type declarations are different that the type
specification of a structure, such as an X509Certificate and its
TBSCertificate. These are type applied, in similar fashion to NeoJSON, will
forecite and predeterminization on both encoding and decoding sides. These type
definitions are applied ad-hoc. In the case of an external type declaration, as
understood so far, these declare new types recognizable by the internal type
identification.
Why is important to system? When presentation layer is decoding a message,
arbitrary objects may be encoded inthe graph of arguments or receiver. As these
are discovered in tracing these graphs, these arbitrary objects will have ASN.1
schema definitionModels from the declarations and should de/manifest
appropriately. Hopefully.
- HH
> Original Message
> Subject: Re: [Pharo-dev] [squeak-dev] Serializers/Encoders
> Local Time: August 15, 2017 2:28 AM
> UTC Time: August 15, 2017 6:28 AM
> From: he...@callistohouse.club
> To: Squeak-dev , Pharo Development
> List
>
> After more research, including TJSON, we realized the choice of ASN.1 at the
> lower layer is exactly what could continue at the higher layer, with more
> work to expand ASN.1 capability.
>
> Sorry for the huge 1 MB image. The classes in Fuel are, beginning with
> serialization or demanifestation:
>
> Serializer
> * Serialization
> * Analyzer
> * Encoder
> ** Analysis
> ***[] Clusterizations { handling source-substitutions }
>
> onthe wire these clusterizations are encoded. On the receiving side, the
> process of materialization or manifestation is straightforwards, activate the
> clusterizations, with a decoder forming a proxy instance graph, then
> annealing them as references. I think these are the points of substitution,
> but I am honestly guessing from a faint memory.
>
> Materializer
> * Materialization
> * Decoder
> (***[]) on the wire clusterizations...
>
> I really want/need/desire to dive into where and how substitutions are
> occurring, on source-side and destination. This in order to add this ability
> to the ASN.1 system.
>
> In ASN.1 specification, there is a mechanism to specify external structures
> and expand the definitional nature of ASN.1. ASN.1 carries a notation and we
> have the start of a DefinitionModel. Fitting this into Fuel would be sweet
> and it may be straightforward: break the graph walking of ASN.1 just have the
> target encoding, in nesting: so pre and post, and change the Fuel
> Encoder/Decoder. I believe that since clusterizations will not pass across, a
> decode analyzer will be needed.
>
> Getting III (Interactive Invocation Interface) support to generate ASN.1
> definition models and classes to model them, bi-directionally, will enable
> the analyzers to setup clusterizations that en/decode properly. Here's to
> hope that this will be so.
>
> Among the varied requirements, the core requirement is passing extended
> substitutable types/schemas between environments: Squeak - Pharo - Java. I
> think ASN.1 with its types is the best choice. I have no idea if Bouncy
> Castle can support external types. I am happy it can do CHOICE, though with
> manual coding to implement this. Separating the Types in Squeak/Pharo
> Cryptograghy turns out to be a good choice and interchangeable we hope.
>
> I hope this clarifies and illuminates, I am driven to share these thoughts.
>
> Warmly,
> - HH
>
>> Original Message
>> Subject: Re: [squeak-dev] [Pharo-dev] Serializers/Encoders
>> Local Time: August 14, 2017 6:27 PM
>> UTC Time: August 14, 2017 10:27 PM
>> From: he...@callistohouse.club
>> To: Pharo Development List , Squeak-dev
>>
>>
>> In further consideration, what seems missing from JSON encoding is an ANY
>> type and a CHOICE type. With these and proper type encoding extension to
>> JSON, we could pass arbitrary types w/o being required to specify a specific
>> decoding structure. I think this is so. Types would be helpful. I found
>> TJSON, which may be good, but no arbitrary types, still.
>>
>> I notice JSON decoding is where magic happens and it requires full
>> specification of what is expected. Perhaps there is a way for ANY & CHOICE
>> with a CustomMapper. Contrarily, Fuel does all analysis on encoding, the
>> front side, and encodes the found clusters on-stream so the materialized is
>> lightweight. ASN1MODULES does a little of both with external types but also
>> with ANY & CHOICE.
>>
>> In looking at Fuel-Core, here are main classes..,
>>
>> - HH
>>
>> On Mon, Aug 14, 2017 at 13:44, henry wrote:
>>
>>> I fin
Re: [Pharo-dev] eventual crashes pharo vm
Yes, here it is, in Pharo6.1, as mentioned previously. Just run the eventual_test tests and it will exit on Ubuntu 32-bit. https://ufile.io/pa9ym Thank you, - HH > Original Message > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 7:45 PM > UTC Time: August 14, 2017 11:45 PM > From: eliot.mira...@gmail.com > To: henry > Pharo Development List > > Hi Henry, > > On Mon, Aug 14, 2017 at 3:58 PM, henry wrote: > >> If you need more info, please ask and I will try to get ths to you. > > yes, if you can make the image & changes available somewhere that would be > nice. Thanks. > >> - HH >> >>> Original Message >>> Subject: Re: [Pharo-dev] eventual crashes pharo vm >>> Local Time: August 14, 2017 6:54 PM >>> UTC Time: August 14, 2017 10:54 PM >>> From: he...@callistohouse.club >>> To: Eliot Miranda >>> Pharo Development List >>> >>> Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on >>> ubuntu 32-bit. Here is the vm version info below. >>> >>> I loaded this package and ran the tests and it >>> exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz >>> >>> Here is the pharo 6.1 version... >>> 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur >>> VM] >>> CoInterpreter VMMaker.oscog-eem.2254 uuid: >>> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >>> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> Date: Thu Jul 20 12:42:21 2017 -0700 $ >>> Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >>> $ >>> Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic >>> #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 >>> GNU/Linux >>> plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: >>> /usr/local/lib/pharo/5.0-201707201942/] >>> >>> - HH >>> >>>> Original Message >>>> Subject: Re: [Pharo-dev] eventual crashes pharo vm >>>> Local Time: August 14, 2017 6:47 PM >>>> UTC Time: August 14, 2017 10:47 PM >>>> From: eliot.mira...@gmail.com >>>> To: henry , Pharo Development List >>>> >>>> >>>> Hi Henry, >>>> >>>> On Sun, Aug 13, 2017 at 5:08 AM, henry wrote: >>>> >>>>> Hi all. I was testing with this eventual_test package and it blows up the >>>>> pharo 6.1 vm. I'd welcome pointers >>>>> >>>>> http://www.squeaksource.com/TurquoiseTesting.html >>>> >>>> Care to share how to reproduce the crash? Image version, VM version & >>>> word size, OS, Smalltalk expression, supporting files, if any. >>>> >>>> _,,,^..^,,,_ >>>> best, Eliot > > -- > _,,,^..^,,,_ > best, Eliot
Re: [Pharo-dev] eventual crashes pharo vm
If you need more info, please ask and I will try to get ths to you. - HH > Original Message > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:54 PM > UTC Time: August 14, 2017 10:54 PM > From: he...@callistohouse.club > To: Eliot Miranda > Pharo Development List > > Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on > ubuntu 32-bit. Here is the vm version info below. > > I loaded this package and ran the tests and it > exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz > > Here is the pharo 6.1 version... > 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Jul 20 12:42:21 2017 -0700 $ > Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic > #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux > plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: > /usr/local/lib/pharo/5.0-201707201942/] > > - HH > >> Original Message >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 14, 2017 6:47 PM >> UTC Time: August 14, 2017 10:47 PM >> From: eliot.mira...@gmail.com >> To: henry , Pharo Development List >> >> >> Hi Henry, >> >> On Sun, Aug 13, 2017 at 5:08 AM, henry wrote: >> >>> Hi all. I was testing with this eventual_test package and it blows up the >>> pharo 6.1 vm. I'd welcome pointers >>> >>> http://www.squeaksource.com/TurquoiseTesting.html >> >> Care to share how to reproduce the crash? Image version, VM version & word >> size, OS, Smalltalk expression, supporting files, if any. >> >> _,,,^..^,,,_ >> best, Eliot
Re: [Pharo-dev] eventual crashes pharo vm
Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on ubuntu 32-bit. Here is the vm version info below. I loaded this package and ran the tests and it exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz Here is the pharo 6.1 version... 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 GNU/Linux plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: /usr/local/lib/pharo/5.0-201707201942/] - HH > Original Message > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 6:47 PM > UTC Time: August 14, 2017 10:47 PM > From: eliot.mira...@gmail.com > To: henry , Pharo Development List > > > Hi Henry, > > On Sun, Aug 13, 2017 at 5:08 AM, henry wrote: > >> Hi all. I was testing with this eventual_test package and it blows up the >> pharo 6.1 vm. I'd welcome pointers >> >> http://www.squeaksource.com/TurquoiseTesting.html > > Care to share how to reproduce the crash? Image version, VM version & word > size, OS, Smalltalk expression, supporting files, if any. > > _,,,^..^,,,_ > best, Eliot
Re: [Pharo-dev] Fuel fails in squeak
I am coding in Squeak as I am unable to load in Pharo, as previously mentioned. I will investigate Fuel versions, thank you. - HH On Mon, Aug 14, 2017 at 13:36, Stephane Ducasse wrote: > I checked and in Pharo 60 MCSmalltalkhubRepository owner: 'Pharo' project: > 'Fuel' user: '' password: '' Now Fuel is by default loaded into Pharo so may > be you have another scenario. Stef On Mon, Aug 14, 2017 at 7:02 PM, henry > wrote: > I loaded the latest Fuel from squeak source and it fails when > materializing > a Character from a FixedObjectCluster. Character class does > not support > basicNew. > > Helpful>?? > > - HH > > @callistohouse.club>
Re: [Pharo-dev] Fuel fails in squeak
Alright, thank you, I will investigate. I attempted to create a SmalltalkHub account but I am unable to create a project. I am slightly overwhelmed at the fractious nature of repositories, between and within Squeak & Pharo, and also encoder serializations. I hope for reconsolidation. - HH On Mon, Aug 14, 2017 at 13:28, Stephane Ducasse wrote: > Hi Henry I do not think that Fuel is managed from SqueakSource. Fuel is > central to Pharo so it should be under Pharo.. Have a look at the repo > associated with the fuel package in Pharo 60 for example. Sent from a phone > that is not trendy On Mon, Aug 14, 2017 at 7:02 PM, henry wrote: > I loaded > the latest Fuel from squeak source and it fails when materializing > a > Character from a FixedObjectCluster. Character class does not support > > basicNew. > > Helpful>?? > > - HH > > @callistohouse.club>
Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?
Nice. - HH > Original Message > Subject: Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript? > Local Time: August 14, 2017 2:38 AM > UTC Time: August 14, 2017 6:38 AM > From: frank.berger.softw...@web.de > To: pharo-dev@lists.pharo.org > > Hello Craig, > > upfront thank you very much for being willing to respond to my problems and > questions. > > As I tried to make clear in this and the neighboring thread: > http://forum.world.st/PharoJS-crashes-at-first-try-td4960686.html > I am looking for a serious "professional" solution to combine server-side > Smalltalk with client-side JavaScript, which is sourced in the same > Smalltalk image that runs the server. This is an essntial part of all of my > product plans and ideas. I am only in software for mass-markets (Fremium > principle) and not in customer-centric projects like most Smalltalkers. > > Another important background: My quite large Smalltalk famework contains the > greatest parts of the data that defines the UI and, second, I have very > specific plans for the UI in the long run, because the UI decides mostly > about the success or failure of an application software. > > There are currently three "candidates": ST2JS, Orca and PharoJS. > > As you can read in the second thread (see link above) the PharoJS image > failed at first attempt. Therefore my question, are you aware of a working > image? > > Second, is there anywhere some detailed information available about what > PharoJS does and, at least basically, how it"s done? (Side-remark: This part > is excellent for Orca, I recommend the Orca papers. Brilliant concepts!) > > Third, are you aware of real-life solutions based on PharoJS? > > I am currently still at the very beginning of my investigations and my very > first impression of PharoJS was the worst possible: The trial image failed > at first attempt and, even worse, neither general documentation nor > code/class comments were available. Both are a no-go for me, being a > "documentation fanatic" out of very long experience in software development. > > Thank you in advance for a short comment. > > Frank > > -- > View this message in context: > http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p4960895.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?
Nice. - HH > Original Message > Subject: Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript? > Local Time: August 14, 2017 2:09 AM > UTC Time: August 14, 2017 6:09 AM > From: cr...@blackpagedigital.com > To: Pharo Development List > > Hi-- > > Eliot writes to Frank: > >> Craig Latta has done some strong work integrating Squeak and Pharo >> with the browser using a bridge derived from Bert Freudenberg"s >> SqueakJS. Craig"s work allows one to use Pharo running on the >> standard Cog VM, client side, to render to the browser, receive >> events from the browser, and manipulate the DOM. >> >> You could contact him to find out if his work is relevant to you. He >> isn"t comfortable discussing it on the Pharo lists himself. > > Oh, I"m plenty comfortable discussing it on the Pharo lists. :) I > was referring to different context in which someone asked me a question > here, and I got attacked for responding to it. > > Anyway, yes: livecoded Pharo in web browsers is working. > > thanks! > > -C > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > cr...@blackpagedigital.com > voice through 2017-09-12: > + 1 510 833 5799 (SMS ok) > +31 20 893 2796 (no SMS)
Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?
Nice. - HH > Original Message > Subject: Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript? > Local Time: August 13, 2017 10:48 PM > UTC Time: August 14, 2017 2:48 AM > From: eliot.mira...@gmail.com > To: Frank Berger Software , Pharo Development > List > > Hi Frank, > > On Aug 12, 2017, at 1:24 PM, Frank Berger Software > wrote: > >> Hello, >> >> the available documentation on Orca looks brilliant and the source, >> Hasso-Plattner-Institut in Potsdam, has an excellent reputation. It looks >> all very professional. >> >> I am therefore most suprised that I cannot find any tracks of usage of Orca, >> neither here, nor elsewhere on the net, and not even any serious discussions. >> >> Does anybody here have practical experience with Orca? >> Critics? >> Recommendations? > > Craig Latta has done some strong work integrating Squeak and Pharo with the > browser using a bridge derived from Bert Freudenberg's SqueakJS. Craig's work > allows one to use Pharo running on the standard Cog VM, client side, to > render to the browser, receive events from the browser, and manipulate the > DOM. > > You could contact him to find out if his work is relevant to you. He isn't > comfortable discussing it on the Pharo lists himself. > >> My goal is to use it for a real-life business application rather than the >> ST2JS, which would be the second alternative. All of my server software is >> written in Smalltalk anyway. >> >> Thank you in advance for any comment. >> >> Frank
Re: [Pharo-dev] eventual crashes pharo vm
Re-adding the list in case others were interested. - HH > Original Message > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 13, 2017 3:59 PM > UTC Time: August 13, 2017 7:59 PM > From: he...@callistohouse.club > To: Stephane Ducasse > > Stef, please see version 4 and the test in RefIdentityTest. > > - HH > >> Original Message >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 13, 2017 3:09 PM >> UTC Time: August 13, 2017 7:09 PM >> From: stepharo.s...@gmail.com >> To: henry >> >> Does he do it systematically? >> I was checking if they extend blockcontext or others. >> Because it would be really nice. >> >> Stef >> >> On Sun, Aug 13, 2017 at 9:06 PM, henry wrote: >>> Sorry, loading works fine. It segfaults on Ubuntu 32-bit when I run the test >>> cases. >>> >>> - HH >>> >>> >>> Original Message >>> Subject: Re: [Pharo-dev] eventual crashes pharo vm >>> Local Time: August 13, 2017 2:58 PM >>> UTC Time: August 13, 2017 6:58 PM >>> From: stepharo.s...@gmail.com >>> To: henry , Pharo Development List >>> >>> >>> We have some instability with the VM. Now can you tell us more how it "blew >>> up"? >>> I browsed the code and nothing special jump to my eyes. >>> >>> Stef >>> >>> On Sun, Aug 13, 2017 at 2:08 PM, henry wrote: >>>> Hi all. I was testing with this eventual_test package and it blows up the >>>> pharo 6.1 vm. I"d welcome pointers >>>> >>>> http://www.squeaksource.com/TurquoiseTesting.html >>>> >>>> - HH >>>> >>>> >>> >>>
Re: [Pharo-dev] Add JSONSchemas to NeoJSON
Thank you, Stef. I sent to him email, conditioned on his enjoying his vacations. - HH > Original Message > Subject: Re: [Pharo-dev] Add JSONSchemas to NeoJSON > Local Time: August 13, 2017 2:53 PM > UTC Time: August 13, 2017 6:53 PM > From: stepharo.s...@gmail.com > To: henry , Pharo Development List > > > Hi henry > > Here is the email of sven Van Caekenberghe > > He is probably on vacation else he would have replied. > This is great if you can extend neoJSON it is a nice and important > piece of software. > > Stef > > On Sat, Aug 12, 2017 at 10:04 PM, henry wrote: >> Is Sven still working on NeoJSON? I want to help expand it to use >> JSONSchemas. >> >> https://spacetelescope.github.io/understanding-json-schema/ >> >> I was looking at ASN1Module in Cryptography... >> >> - HH
Re: [Pharo-dev] Add JSONSchemas to NeoJSON
Hello Esteban, Do you have Sven's email? I would like to discuss with him. I am currently considering combining ASN1 Modules, Fuel substitution and NeoJSON encoding. It is some work. Regards, - HH > Original Message > Subject: Re: [Pharo-dev] Add JSONSchemas to NeoJSON > Local Time: August 12, 2017 6:13 PM > UTC Time: August 12, 2017 10:13 PM > From: emaring...@gmail.com > To: henry , Pharo Development List > > > Sven is still the developer and maintaner of NeoJSON. > > It would be nice to have JSON Schemas in NeoJSON. You could abort the > read of a stream if the schema is invalid, without > having to build the whole object tree or to parse the whole stream. > > Regards! > > Esteban A. Maringolo > > 2017-08-12 17:04 GMT-03:00 henry : >> Is Sven still working on NeoJSON? I want to help expand it to use >> JSONSchemas. >> >> https://spacetelescope.github.io/understanding-json-schema/ >> >> I was looking at ASN1Module in Cryptography... >> >> - HH
[Pharo-dev] eventual crashes pharo vm
Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers http://www.squeaksource.com/TurquoiseTesting.html - HH
Re: [Pharo-dev] Add JSONSchemas to NeoJSON
To be honest, I looked at Fuel, but it has changed: I can't find the FLDecoder. I had hoped such a framework could switch to JSon encoding, as the substitution framework is robust. I do not know if it's feasible. - HH On Sat, Aug 12, 2017 at 19:09, henry wrote: > I also need callbacks for substituation during encoding, SAX-like. I think > custom mapping of NeoJSON does this, with clusters. But I am unsure. > > - HH > > On Sat, Aug 12, 2017 at 19:07, henry wrote: > >> I would like to help bring JSON Schemas to NeoJSON. I need that ability. >> >> - HH >> >> On Sat, Aug 12, 2017 at 18:13, Esteban A. Maringolo >> wrote: >> >>> Sven is still the developer and maintaner of NeoJSON. It would be nice to >>> have JSON Schemas in NeoJSON. You could abort the read of a stream if the >>> schema is invalid, without having to build the whole object tree or to >>> parse the whole stream. Regards! Esteban A. Maringolo 2017-08-12 17:04 >>> GMT-03:00 henry : > Is Sven still working on NeoJSON? I want to help expand >>> it to use > JSONSchemas. > > >>> https://spacetelescope.github.io/understanding-json-schema/ > > I was >>> looking at ASN1Module in Cryptography... > > - HH @callistohouse.club>
Re: [Pharo-dev] Add JSONSchemas to NeoJSON
I also need callbacks for substituation during encoding, SAX-like. I think custom mapping of NeoJSON does this, with clusters. But I am unsure. - HH On Sat, Aug 12, 2017 at 19:07, henry wrote: > I would like to help bring JSON Schemas to NeoJSON. I need that ability. > > - HH > > On Sat, Aug 12, 2017 at 18:13, Esteban A. Maringolo > wrote: > >> Sven is still the developer and maintaner of NeoJSON. It would be nice to >> have JSON Schemas in NeoJSON. You could abort the read of a stream if the >> schema is invalid, without having to build the whole object tree or to parse >> the whole stream. Regards! Esteban A. Maringolo 2017-08-12 17:04 GMT-03:00 >> henry : > Is Sven still working on NeoJSON? I want to help expand it to use >> > JSONSchemas. > > >> https://spacetelescope.github.io/understanding-json-schema/ > > I was >> looking at ASN1Module in Cryptography... > > - HH @callistohouse.club>
Re: [Pharo-dev] Add JSONSchemas to NeoJSON
I would like to help bring JSON Schemas to NeoJSON. I need that ability. - HH On Sat, Aug 12, 2017 at 18:13, Esteban A. Maringolo wrote: > Sven is still the developer and maintaner of NeoJSON. It would be nice to > have JSON Schemas in NeoJSON. You could abort the read of a stream if the > schema is invalid, without having to build the whole object tree or to parse > the whole stream. Regards! Esteban A. Maringolo 2017-08-12 17:04 GMT-03:00 > henry : > Is Sven still working on NeoJSON? I want to help expand it to use > > JSONSchemas. > > https://spacetelescope.github.io/understanding-json-schema/ > > > I was looking at ASN1Module in Cryptography... > > - HH > @callistohouse.club>
[Pharo-dev] Add JSONSchemas to NeoJSON
Is Sven still working on NeoJSON? I want to help expand it to use JSONSchemas. https://spacetelescope.github.io/understanding-json-schema/ I was looking at ASN1Module in Cryptography... - HH
