seasidest / grease Goto Github PK

The GemStone primitives on GsFile are not encoding a filename with non-ascii chars. As a consequence, users must not forget to properly encode these filenames before using the primitives.

For example, executing the following in GemStone 2.4, 3.1 or 3.2 does not open the file because it does not find it.
GRPlatform current contentsOfFile: 'fichier français à importer.txt' binary: false

If we encode the filename, it works:
GRPlatform current contentsOfFile: 'fichier français à importer.txt' encodeAsUTF8 binary: false

I think this might be a GemStone issue that could be fixed if the primitives take the user locale into account. What do you think @dalehenrich ? In the meantime, we might want to abstract this into Grease with a locale that can be set in GRPlatform and that is subsequently used to encode the filename.

But it's loading just fine when I do the load manually with GsUpgrader in a local installation.
Seems like something goes wrong loading metacello but only on Travis...

Any clue @dalehenrich ?

Because Pharo 1 is not maintained anymore.

Now that all the dialects we support have block closure I think it's worth considering removing #fixCallbackTemps

On Pharo we have now a class PackageManifest who can be subclass in all packages of the system to keep meta datas (for example for CriticBrowser banned rules).
This PackageManifest class could maybe be added in other smalltalk than Pharo to ensure the compatibility.

• Color >> #asHTMLColor is gone in Pharo 6 but the only senders are tests. Why do we test this method?
• Smalltalk #removeFromShutDownList: is gone, #addToStartUpList: is still there though
• GRStringTest >> #testSubStrings breaks but it tests ANSI behaviour
• GRSlimeTest >> #testUsesCurlyBraceArrays breaks but that looks like and RB bug

I tried to load MDL in Pharo 8 but it failed because Pharo 8 is not defined for grease. It will probably be the same for Seaside.

Because of #43 #test greaseString now returns a Symbol instead of a String.

Because now Pharo 1 and 2 compatibility is dropped

Given an empty file somefile, the following returns nil instead of an empty instance of ByteArray.

GRPlatform current contentsOfFile: 'somefile' binary: true

This is not consistent with text files (which return an empty instance of String), nor with previous Pharo versions.

The change is caused because of #106

In Pharo 7 the class Base64MimeConverter should be avoided and it is better to use:

base64Decoded
base64Encoded

on String.

So GRPharoPlatform>>base64Decode: aString should be changed from

base64Decode: aString
	^ (Base64MimeConverter mimeDecodeToChars: aString readStream) contents

to

base64Decode: aString
	^ aString base64Decoded

Looking at our coveralls results I found out that we don't run GRAbstractDictionaryTest for GRSmallDictionary.

Apparently GRPlatform on VASt has a #thisContext method as replacement for a missing thisContext variable. Gemstone/S also has not thisContext variable and has to change all the continuation code.

A default implementation could look like this

thisContext
  ^ thisContext sender

The dev branch should be renamed to develop to match the Seaside repository.

(original issue disappeared because old Grease repo was removed)

@dalehenrich was wondering why comparison was not defined on GRSmallDictionary while he is working on porting STON to GemStone. Instead of porting SmallDictionary, he wants to use GRSmallDictionary. However, this requires a comparison to be defined on that class.

All the stream tests seem to be working with WriteStream on Pharo 6+. We can probably remove the class.

https://code.google.com/p/glassdb/issues/detail?id=355

Loading Seaside through

Metacello new
configuration:'Seaside3';
repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
version: #stable;
load.

it tries to use CoS 335 and CoG 344. That referes to a #'release1' that cannot be found. Manually loading 343 fixes it.

The following code

GRSmallDictionary2 new
	at: 'x' put: 'x';
	at: 'y' put: 'y';
	at: 'z' put: 'z';
	removeKey: 'z'

produces a subscript out of bounds. Tested in Pharo 7.

This is a simplified example, we hitted this problem in some Seaside code trying to remove some keys from the arguments of a JSObject.

glassdb/Seaside31#21 really belongs here, since this is where the work is being done ..

We now have a #thisContext method for dialects that do not have a thisContext variable.

In order to get the tests running and the #stackDepth method working we need the following API:

• #sender: Answer the context that sent the that created the receiver. Can either be a block or or method context. Is nil for the topmost stack frame.

In order to get WAPharoWalkback to work we need the following API:

• #receiver: Answer the receiver object of the message receiver. Can be a block object.
• #printStringLimitedTo:
• #tempAt: Answer the temporary variable at the given index.

We used to send #tempScopedNames but that seems to be gone.
We used to send more messages but this seems to be the only part of the Pharo context API that is guaranteed to work.

There are references to thisContext in methods named evaluate that read something like

evaluate
	"GemStone does not have a thisContext variable..."

	^input evaluateInContext: self object symbolList: GsSession currentSession symbolList

I left out what we need for continuations since they're going to be different for GemStone anyway.

Since they are GemStone specific anyway I don't know how much replacing these makes sense.

In this travis build, 3.5.0 tests are failing. We are getting an ObjectSecurityError and that is odd because a month ago, the travis tests passed
the 3.5.0 release hasn't changed for three years ... so something else in the build pipeline has changed in the last month ...

The class was never functional and now it was removed in GemStone 3.3:

Warning: This package depends on the following classes:
  Process
You must resolve these dependencies before you will be able to load these definitions: 
  Process>>properties

Loaded -> Grease-GemStone-Core-dkh.56 --- filetree:///opt/git/Grease/repository [6a76165:dev] --- cache

Can afford to just remove the method completely ...

Like SeasideSt/Seaside#1017

We no longer support Pharo 3 with Seaside, can we also drop support for Pharo 3 in Grease? Then we could go metadataless.

Symbol>>asMutator is deprecated in Squeak. Implement greaseAsMutator to deal with the new platform difference.

Add a GRNotificationBasedDynamicVariable that works like the legacy WADynamicVariable in order to ease ports that do not have dynamic variables or thread/process local variables.

We should have a Pharo 6.1 build

The current Pharo packages are done so that code duplication is minimised but the result is very confusing. Eg. Grease-Pharo30-Core and Grease-Pharo40-Core are both loaded into a Pharo 5 image.

I wonder if it would be better to just copy and paste the packages for every dialect version.

For better debugger integration in Pharo we could add the following methods

For GRSmallDictionary class

inspectorClass
	^ EyeDictionaryInspector

For GRSmallOrderedSet class

inspectorClass
	^ EyeCollectionInspector

Maybe they should go into a Grease-Pharo-Spec package so we don't get undeclareds in minimal images.

Failing test: GRDynamicVariable>>defaultValue

GRIntervalTest >> #testSorted assumes new a collection is returned. This is no longer true with the latest Squeak.

The current HEAD of master seems to be pharo7 compatible. A new release where we can point at would be nice

There is some duplication that can be factorized in Pharo baseline.

GemStone 3.5.0 will be released "soon" ... also update the gemstone lineup to cover more recent releases ...

Contrary to popular belief, the GLASS1 baseline uses GsDevKit/Grease, not SeasideSt/Grease, despite that, it seems that the actual code loaded into GemStone is identical in both repositories, so it is a technical difference at the moment.

3.6.0 will require some changes in Grease (it looks like), so it seems to be a good time to make the switch.

The major impact is that GsDevKit_home will start cloning SeasideSt/Grease for new installations (GsDevKit/GsDevKit_home#295) and I will be looking into trying to automate the update for old installations ..

Integer printing in GRNumberPrinter allocates a lot of Strings rather than rendering directly to the stream.

The GRPlatform>>fileStreamOn:do:binary: offers read access to files. There is not GRPlatform>>writeFileStreamOn:do:binary: method to stream contents to a file. Instead, users of Grease must use GRPlatform>>write:toFile:inFolder.

This is specifically of interest to #103, where it was also raised we are lagging behind the FileStream deprecation in Pharo.

Loading Grease as part of Seaside 3.3 is interrupted by the missing GRNotificationBasedDynamicVariable

From @marschall on October 4, 2015 15:6

Hi, today I noticed I had a dirty Kernel package in Squeak 5 due to
Grease overrides of three methods. Squeak has subsequently made
improvements to these methods which may be able to be adopted by
Pharo. They were changed in 2011 to not create a temporary Array.

MessageSend>>#value:
MessageSend>>#value:value:
MessageSend>>#valueWithPossibleArgs:

All the Grease, JQuery, Javascript and Seaside tests passed with the
modern versions. The Squeak 5 version of these methods is in the
attached changeset.

Best,
Chris

http://lists.squeakfoundation.org/pipermail/seaside-dev/2015-October/006682.html

Copied from original issue: SeasideSt/Seaside#858

In Pharo 5 and 6 (at least) there is no class MailSender but Grease-Pharo30-Core reference this class.

See GRPharoPlateform>>seasideSmtpServer.

On GemStone 3.3 and beyond, the hack of changeClassTo: to convert strings to UTF8 fails. Moreover, #_encodeAsUTF8intoString was added into the system so we should use that.

The new code should be:

GRUtf8CodecStream>>nextPutAll: 
  binary
    ifTrue: [ stream nextPutAll: aString asString ]
    ifFalse: [ stream nextPutAll: aString _encodeAsUTF8intoString ]

 Utf8>>asString
    ^ self decodeToUnicode

The whole discussion of this fix is in a thread "Again, Corrup Error preventing debugging real seaside exception" on the GLASS mailing list.

I am a bit out of time right now to setup everything to make a PR, but I will see if I have time later.

For a better debugging experience in Pharo we should consider Glamour integration for things like GRSmallDictionary and GRSmallOrderedCollection.

Dictionary has quite a few methods dedicated to this #gtInspectorItemsIn:, #gtInspectorKeysIn:, #spotterForKeysFor:, #gtDebuggerSUnitPrint.

Maybe they should go into a Grease-Pharo-Glamour package so we don't get undeclareds in minimal images.

Since they are not supported anymore.

Mariano encountered difficulty doing nested tasks using Seaside ...

And I found a patch to GRGemStonePlatform>>callbackMarker that doesn't seem to be a horrible hack ... anyway, Mariano will take this patch for a spin and if he doesn't run into further problems, we'll want to include this in an upcoming release...

Loading Grease to Pharo 9 does not load Pharo-specific packages.

Probable reason is that Grease baseline has each Pharo version explicitely named in baseline and there is no entry for Pharo 9 yet.

We still have explorer support for GRSmallDictionary in Grease-Pharo60-Core.

After updating ConfigurationOfGrease identical to how ConfigurationOfSeaside3 works to reference the baseline, the build breaks for Gemstone 2.4

Need to find a solution... ?

GROrderedMultiMap >> keys are not unique and can contain duplicates. The tests even verify this. Is this the behaviour we want?