Update: Progress ...

[James Ladd]

Hi Redliners,

I continue to work on Redline and I'm very pleased with the progress of the
Compiler.
I have started to implement the Kernel Classes as part of the Runtime.

If you would like to help then please let me know as it would help get
Redline to
a release version.

- James.




--
View this message in context: http://forum.world.st/Update-Progress-tp4932051.html
Sent from the Redline Smalltalk mailing list archive at Nabble.com.

[Apokalypse Software Corp]

I'm very interested in seeing this released.

I'm primarily interested in having the Smalltalk language on the JVM for the apps I'm already working on. Having the historical classes would be of secondary value for me at this time, important for ports and future work.

I tried building Redline from sources, and the master branch throws an exception on macOS Sierra 10.12.3, on visitExpression. The before-squeaking branch builds without an exception. But the debugging output definitely needs to be squelched.

Like others mentioned on another thread, the IDEA plugin fails to load Redline's SDK into the environment for recent IDEA releases. I was able to eliminate most of the compilation by tracking down the changes to the IDEA Plugin API, but I doubt all the needed plugin lifecycle methods are now in place. I'll know once I've gotten all the remaining errors replaced and perhaps some deprecations resolved. The largest hurdle I see remaining is getting SmalltalkParser.java to compile. I believe it's generated by some tool in the Plugin SDK, but how to get it to generate one using the current Plugin API is currently beyond me.

I was able to get the Eclipse plugin to build using the Kepler release. I have updated my fork and submitted a pull request for those changes. However, I've not been able to get it to build using Neon. Some additional changes to the Xtext API, build environment, yadda yadda, will be needed. Maybe sometime soon.

I'd like to help bring things up to date with the latest JVM environments, but I don't know how much our objectives are linked after that point. I'm looking for a Smalltalk compiler to emit regular bytecodes for the regular and Android JVMs, as a replacement for Java and other programming languages. I'm not looking to recreate the Smalltalk environment on JVM just yet, as that route has already failed for practically every other Smalltalk implementation. I think a Smalltalk compiler to be used in place of Java, Groovy, JRuby, Scala and the rest would be a far more attractive proposition to most programmers.

Anyhow, my help is offered, and everyone else's help is appreciated in getting this moved forward.

Warmest regards,
Alfonso Guerra
Founder/CEO
Apokalypse Software Corp.
(626) 667-4285

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Ladd]

Hi Alfonso,

Thank you for reaching out.

I'm stalled on Redline for a while because I was in a startup. I have not got back to RL since there seemed to be

very little interest.

I did a branch of Redline that was a new improved and more complete version yet it still needs work.

I'd love to do more with this but until I have some bills paid etc I have to look at to other things.

- James.

[Apokalypse Software Corp]

I relate completely to your need to pay bills and other human necessities, and disappointment with the apathy to the reception RLS has had in the development community. My own work on a Smalltalk-based system for tree Mac has been stalled over a decade now as well. But you've certainly built up greater interest and engagement for RLS. Well done!

But if I may, I think attempting to recreate the Blue Book implementation in the JVM with full integration is quite an undertaking, and those who expressed an interest at the beginning have their enthusiasm tempered as the realities of the daily grind working with subpar languages have taken their toll.

I believe iterative releases, with simpler objectives, would increase interest. A release which simply allows writing for the JVM directly would give developers interested in something new an opportunity to try out Smalltalk's syntax in a practical way. It would also allow those of us who prefer its cleaner syntax a way to use it in the projects and environments we currently contend with.

As this initial implementation gives us time to build a larger community, we can continue recreating the Blue Book system for JVM (activated simply by importing the Smalltalk classes), add support for the Monticello repository, and other work.

I know interest in Smalltalk continues to grow (simply because the number of developers is growing, and many hear about Smalltalk for some reason), but the lack of an implementation that fits into their current workflow and build system hampers usage and adoption. I would prefer using Smalltalk to write desktop and mobile apps and know others would too.

This is my recommended course of action and what I'm currently working towards.

Warmest regards,

Alfonso Guerra
Founder/CEO
Apokalypse Software Corp

@Huperniketes
(626) 667-4285

[James Ladd]

Hi Alfonso.

Writing a proper smalltalk is quite the undertaking and I am / was making great progress.

I did have some initial people interested in helping and they did but quickly dropped off.

I agree with your comments about a simpler and smaller releases and I have been thinking

about this a lot. However, if just the compiler/interpreter was released people would probably

not do much with it because there isn't a library to help - catch 22.

I'm still keen to finish Redline and I have been thinking of ways to achieve this along the

same lines as you. Hopefully soon Ill get some space to give this a try and put something 

out there.

- James.

[Apokalypse Software Corp]

On Sep 18, 2017 6:02 PM, "James Ladd" <ladd....@gmail.com> wrote:

Hi Alfonso.

Writing a proper smalltalk is quite the undertaking and I am / was making great progress.

I did have some initial people interested in helping and they did but quickly dropped off.

Yes, your work on the full Blue Book implementation certainly is desirable andI look forward to using it and hopefully contributing to it as well. I'm sure once the community grows further, others who feel it lacks the particular Smalltalk feature they MUST have will also contribute.

I agree with your comments about a simpler and smaller releases and I have been thinking

about this a lot. However, if just the compiler/interpreter was released people would probably

not do much with it because there isn't a library to help - catch 22.

I disagree. I would be happy to use the Smalltalk language linked to the Java JDK and Android SDK, and I believe others would too. That should bring enough interested developers who'll help contribute more code for proper Blue Book support, etc.

I believe it's the Smalltalk aficionados insistence on having that complete Blue Book environment, with its incompatibility with the rest of the programming environments which have hindered its adoption while inferior languages like Perl, PHP, Ruby, Java, etc have far larger communities.

I'm still keen to finish Redline and I have been thinking of ways to achieve this along the

same lines as you. Hopefully soon Ill get some space to give this a try and put something 

out there.

- James.

I'd be happy to brainstorm this further with you, off-list if you prefer.

[Matt Selway]

Hi Guys,

It is good to see interest in Redline. I have been watching it for a while, unfortunately I have not been able to contribute as I have the same problem, i.e., needing to work on what pays the bills.

RE: writing a proper Smalltalk
How far does integrating the Squeak sources take it?

If it gets us to a reasonable base system, then bringing back the JavaAdaptor that was in one of the early versions of Redline could make a usable system; at least it would for my purposes ;-)

I agree with Alfonso in that the initial trick is getting something reasonably stable that allows applications to be developed, even if it is mostly through Java integration. Then hopefully people would get interested and help bring Smalltalk libraries across as required in their own development.

At one point I started looking into bringing the JavaAdaptor from the original version of Redline into the previous rebuild and I noticed it was pretty incomplete. I wonder if the JNIPort stuff could help get something off the ground quicker? If I recall correctly, it seemed that there were quite a few similarities between the two. It could also just be misleading superficial similarities that would be more trouble than it is worth, but I didn't get the chance to look into it further at the time.

Best Regards,
Matt

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.

[James Ladd]

Happy to brainstorm on or off list ;)

[James Ladd]

There has been a lot of work in Redline that you may not be aware of.

I re-wrote it and made things simpler and faster. My delay or hold up aside from work and life getting in the way was porting a runtime. I chose and early version of Squeak for this (v2.2) as it was v close to the blue book.

I still think that approach was probably folly and I need a basic core interpreter working w the most minimal set of classes possible.

I do get pulled in diff direction by Pharo as I think comparability w them is a huge bonus but equally a ton more work.

I'm thinking seriously about a simpler interpreter as a version 1 capable of running on the Jvm and doing Smalltalk things but SANS a runtime - to me this w be both a step forwards and backwards - even if a Java adaptor was included which it w be.

- James 

Sent from my Commodore 64

[Matt Selway]

I was aware you rewrote it for Java 8 and incorporated Squeak sources, although I assumed it was just a minimal set of classes to get the basics running. I thought "fantastic!" then when to play with it and discovered it couldn't compile Bahavior.st because the parser doesn't quite like the syntax used by Squeak sources (empty blocks and literal arrays were causing errors); unfortunately I didn't have the time to patch it myself and haven't gone back to it to yet.

Compatibility with Pharo would be good, although even they started with Squeak didn't they?
I think a lot of things they are doing with Pharo you might be able to get for free from using the JVM. Traits for example can be done using default methods on interfaces in Java 8, but I don't know how much that would mess with your interpreter nor how difficult it would be to keep it compatible with Pharo's implementation. I liked your initial philosophy (I think back when you were calling for people to adopt a class) of when implementing the core Smalltalk classes that thought be given to how it can be improved using the JVM rather than just a blind implementation of the Blue Book.

I'd definitely support a simple interpreter as step 1 that can be built on later. (Of course my support might have to be metaphorical unfortunately). How easy would it be to cut out unnecessary stuff from what you already have? Or would it be re-write number 3? :-/

Cheers,
Matt

P.S. this conversation is making me want to dive into the code again. If only I had the time :-(

[James Ladd]

>>P.S. this conversation is making me want to dive into the code again. If only I had the time :-(

You too :)

I did fix those issues and had most of the runtime compiling but alas in another branch.

There biggest irony is that the core isn't a massive task, the runtime is and finding time for either the hardest task of all.

Still, like you said - the conversation is building up my interest - maybe just maybe I can do 14hrs a day with some added for RL

- James


Sent from my Commodore 64

[Matt Selway]

There biggest irony is that the core isn't a massive task, the runtime is and finding time for either the hardest task of all.

So true. But maybe you can find time to push that other branch to GitHub. ;-)

Who needs sleep, right?

Out of curiosity, did you ever work out what the minimal set of classes would be?

[James Ladd]

My think the minimum has be be the core classes to build objects and send messages and no more - for now 

Sent from my Commodore 64

--

[Apokalypse Software Corp]

I think just emitting bytecodes to call Java methods and substitute classes for its non-OOP primitives, really. Just to get the ball rolling.

We can write additional code in Smalltalk after that.

Warmest regards,
Alfonso Guerra
Founder/CEO
Apokalypse Software Corp.
(626) 667-4285

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

[James Ladd]

Smalltalk (dictionary) and ProtoObject are the bare essentials to ensure message sending - the rest can be built from there.

Still the devil is in the details ;)

Sent from my Commodore 64

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.

[Matt Selway]

Without the JavaAdapter though, would that allow integration with standard Java libraries? Or would you have to resort to emitting bytecodes manually for that? I assume with the rebuild you have kept access to the 'JVM' pseudo variable?

Even with what Alfonso is suggesting, we would still need some kind of translation layer to call the Java methods correctly? Unless ProtoObject can handle that translation itself?
(Maybe I should just look at the code :-P )

Matt

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redline-smallt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Ladd]

Yes I would enable to Java adaptor and or JVM object ;)

Sent from my Commodore 64

[James Ladd]

I think less is more and making a Java Adaptor out of the box while helpful would probably distract from getting real Smalltalk classes done - it's something I'm thinking about 

Sent from my Commodore 64

[James Ladd]

Check out my personal GitHub repo project Stc.

You can follow along if you want.

No guarantees of how often I'll get to move this along ;)

Sent from my Commodore 64

[James Ladd]

Do you want to follow along - anyone?

Sent from my Commodore 64

[Matt Selway]

Cool. Didn't realise you managed to find some time.

[James Ladd]

Not sure where I w find the time either but it's Sunday and I was up early 

Sent from my Commodore 64

[Apokalypse Software Corp]

I'm certainly following along! Although I've begun work from a different angle, hacking the javac parser, I'm looking to contribute to this project too as my understanding of the models matures.

Great work, James!

Warmest regards,
Alfonso Guerra
Founder/CEO
Apokalypse Software Corp.
(626) 667-4285

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

[James Ladd]

Hey Alfonso,

Glad to know you w follow along.

What do you mean by a different angle and javac?

Sent from my Commodore 64

[James Ladd]

I'll be using gitflow and label the branches with what I am trying to and what is completed - hopefully this w help those following along

Sent from my Commodore 64

[Kevin Driedger]

Looked at the code. Are you reusing the old compiler or classloader? Or is everything new.

The smalltalk system even calling just the Java class library would be beneficial.  I would be most interested as well in writing Android apps in smalltalk which seems would largely need to call Java classes (potentially wrapping them nicely as a future endeavor)

Kevin

[Dimitris Chloupis]

I see two problem with smalltalk running on JVM. 

a) JVM is a language graveyard

b) You dont need to run a language on JVM to be able to use Java libraries

About (a) , its easy to see why people would have very little interest about Smalltalk running on JVM , its afterall Smalltalk, we all know the community is too small.

Python on the other hand is not small, its HUGE. Rumors estimate python coders to be over a million and the language is growing more popular by the second. There is a complete project to port Python to JVM , called "Jython". Its very mature, very stable and even has the rare luxury of supporting many pure python libraries and even C Python libraries (c libraries wrapped for python). 

Do you know how much interest Jython gathers ? For the popularity of Python is actually close to zero. Same story with .NET , we have there Ironpython, a bit less stable and less mature but still quite decent Python implementation, the interest there is not zero is actually minus. Of course its not just Python. Its Ruby, JS, Scala , Groovy, Clojure etc. 

I am willing to risk an assumption is that people code Python and Smalltalk because they want to and they code in Java because they have to. That createst a vast gap that makes it near impossible for users to cross.

I toyed with Jython myself when I was learning Java, I even contacted the devs, very nice people and gave them a hand with the documentation and made music for their podcast. But in the end I find it extremely hard to justify Jython over CPython when it came down to ease of use and even power. I did want to deal with Java library or logic. 

Things also are made even worse with (b) option, which is basically IPC (Inter Process Communication) a weatlh of diffirent technicques to make languages talk to each other (as well as applications etc) which allows you to use the libraries of one language from inside another language. I made Atlas, a tiny library that uses sockets to allow the use of Cpython libraries from inside Pharo. Very limited, but if all you want is to call methods and functions , it does the job well. This effort provided inspiration for another project I called CPPBridge which allowed the use of C++ libraries from inside Pharo (Pharo FFI does not allow the use of C++ libraries because of name mangling that it does not support) . Both projects with full support for the usual live coding Smalltalk workflow.  CPPBridge in particular extended the Pharo image to include live C++ objects through its use of shared memory mapped files which work very similar to smalltalk image of course minus the vm bytecode.

In both cases those projects even though they may sound ambitious on paper they are jokes compared to what James has done. They never exceed a handful of hundrends lines of code and their design is super simple. 

In case of Java , Pharo has been lucky in the fact that already has such a tool, last time I checked some people used Java libraries through JNIPort library , a project started outside Pharo that offered support for both Squeak and Pharo. 

A language running on JVM obviously is more ideal than the quick IPC hacks , but because IPC can go much deeper than I did with it, I am pretty sure it can cover a huge array of scenarios that a JVM language would cover too, but with only a  very smalltalk fraction of the effort needed for implementing a language on JVM.

I have huge respect about James work, I would not dare to take such a giagantic project just by myself even with the promise of few other helping me out but that also may have to do with the fact that he is a much better coder than I am. 

I posted this here because my experience with my own IPC project taught me that most people , me included, are not aware how easy it to use libraries of another language through IPC. Generally small projects rarely use IPC unless their goal is IPC orientated  but very large project utilisiing multiple of languages usually do and there are some sophisticated IPC libraries out there like RabbitMQ etc. 

[Apokalypse Software Corp]

I'm looking to use the Smalltalk language in the toolchains for the platforms I'm currently working with: desktops, mobile, web. That way I can use the same source files across the board. The Amber compiler generates Javascript from Smalltalk, and I have a Smalltalk-based language for the desktop which I'll need to revive, but I'm almost there.

A compiler that will generate class files from Smalltalk that can call Swing, Hadoop or Android libraries would be very useful to me. So I'm changing some tokens and modifying the javac lexical analyzer and parser to accept the Smalltalk syntax instead of Java: lambdas, numbers, method calls, control flow statements, etc. The only thing done so far is I've replaced the "this" pseudovariable with "self". Commits will be coming soon.

The repo for the project is at JHagah — Bitbucket, and I'm tracking progress with a trello board.

Warmest regards,
Alfonso Guerra
Founder/CEO
Apokalypse Software Corp.
(626) 667-4285

[Matt Selway]

Sounds good :-)
I just spent a while checking out what you were doing, wondering why it wasn't working, only to realise you're new ByteCodeEmitter is empty :-P

@Alfonso I'm also curious as to what you mean by "hacking the javac parser"

[James Ladd]

Reusing what makes sense to reuse - by sense if there is a part that from experience needs a rewrite in rewriting it

Sent from my Commodore 64

[James Ladd]

Note: I have added an Issue to Github to describe the work I am doing next.

I also describe the branch in the git repo that will contain the work.

When complete this branch will be merged into the main line.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

[James Ladd]

Hi Dimitris,

>>I have huge respect about James work, I would not dare to take such a giagantic project just by myself even with the promise of few other helping me out but that also may have to do with the fact that he is a much better coder than I am. 

Thank you for the kind words. I'm not a better coder just a different one.

The compliment isn't the only thing I took away from what you have said.

I want to code in Smalltalk and I want to use the JVM so making Redline looks like my only path forward ;)

I hope you continue to follow along and make comment.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

[James Ladd]

I'll try and make a commit to a branch tomorrow and if all goes well I'll merge to master - stay tuned

Sent from my Commodore 64

[Matt Selway]

Have you heard of Bistro before? I only came across it recently, but it looks like it compiles a Smalltalk-based language (it has some extensions for Java features such public, private, protected, etc.) into Java. Sounds like that is the type of thing you want.

I am interested in how easy it is to just hack the java compiler though. How does it support Smalltalk features like block closures (since Java's lambdas are not full closures)?

[Matt Selway]

I want to code in Smalltalk and I want to use the JVM so making Redline looks like my only path forward ;)

That's the trick :-D

I've used JNIPort in the past (still am actually), but a more integrated solution would be better I think: less configuration difficulties, hopefully slightly better performance.

There are also some things lacking from Smalltalk implementations that you should be able to get 'for free' by having a JVM implementation. For example, native threads---not always a fan of doing multi-tasking by spinning up more instances of the image---and, hopefully, performance benefits from the JVM's runtime optimisation, among other things.

[James Ladd]

Yes I have looked extensively at Bistro.

Redline seeks to go straight to bytecode w full debug support. No mental manipulation between source and result.

Blocks in Redline support the full semantics you expect - or rather they will- I didn't have this working in a previous version 

Sent from my Commodore 64

[James Ladd]

Proper concurrency is available when using the Jvm and therefore Redline 

Sent from my Commodore 64

[Matt Selway]

Redline seeks to go straight to bytecode w full debug support. No mental manipulation between source and result.

That's one of the things I liked about your approach. You get the Smalltalk code line, not the Java code line. Was hoping it would lead to the full interactive debugging that is normally associated with Smalltalk ;-)

Blocks in Redline support the full semantics you expect - or rather they will- I didn't have this working in a previous version

Didn't realise you didn't have that working properly before :-O

There's always rewrite 5 or 6, right? :-P

So your ByteCodeEmitter creates a class that prints "sendMessages", that's a start :-)

[James Ladd]

Direct to bytecode w proper line by line debugging - that's been there since day 1.

Fully interactive debugging should work too - another reason for hooking into the classloader 

Blocks in Redline always did what Smalltalk blocks do.

Yes - currently the generated class which is a valid Java class w simple output the message 'sendMessage' to the console.

I'm pretty busy w work so I can only make small steps 

Sent from my Commodore 64

[James Ladd]

Thanks for the code snippet - Redline has code to search class path and load the Smalltalk even if it is in a jar - I'm just not calling it yet

Soon I will make the change to search the classpath then people can invoke the redline jar from the command line to exercise the compiler - stay tuned :)

Sent from my Commodore 64

[Matt Selway]

Thanks for the code snippet - Redline has code to search class path and load the Smalltalk even if it is in a jar - I'm just not calling it yet

No worries. I just figured it was the path of least effort so you could focus on what you were really working on :-)

[James Ladd]

Please try Redline from the command line ;)

Sent from my Commodore 64

[Matt Selway]

Done. Works no problem. I'm assuming meant just 'java -jar ...' not using the 'stic' sh script?

Missing the argument, it finds the NoArguments script in the jar fine, with an argument it found it no probs (once I types it correctly anyway).

[James Ladd]

That's correct 

I should update the Stic scrip ;)

Sent from my Commodore 64

[James Ladd]

Glad it worked for you - wondering what is most helpful to implement next.

So many choices right now.

Sent from my Commodore 64

[Matt Selway]

What are the choices?
Isn't it just ByteCode generation, ByteCode generation, ByteCode generation?

[James Ladd]

Yes. But I could focus on the special JVM receiver so Smalltalk methods can be implemented without Java class backing.

I'm sure to settle on anything that gets message sending going 

Sent from my Commodore 64

[Matt Selway]

If you focus on the JVM receiver, can't you just use that to bootstrap the entire system ;-)

[James Ladd]

 Certainly could.

However I have long wrestled w the fact that while the JVM receiver can be used to write the implementation of base methods it also makes for hard reading and a rather foreign feel. 

I'm wrestling w this 

Sent from my Commodore 64

[Dave Mason]

I saw James' presentation on Redline in Edinburgh at ESUG'11 and was very excited! I remain very supportive, contributed a bit to the Indiegogo drive, and am very pleased to see James re-engaged in the project. I haven't had an opportunity to use it but would like it to be there when I next need to deploy on JVM.

So I'm a little hesitant to suggest an alternative path to getting Smalltalk code running on JVM.

As one of the principals of PharoJS.org I have been wondering if a similar path might work for the JVM. For those who may not know, PharoJS - like Amber - is about programming in Smalltalk and deploying on the browser - hence it transpiles to Javascript. The key idea is that rather than replicate the Smalltalk IDE to run on the browser (as Amber does) we want to do all our development in the rich Pharo IDE and only deploy on the browser. I have been thinking for a while that it might be interesting to look at a PharoJVM that took your working Pharo code and emitted a .class file ready to deploy on the JVM.  In reading this thread, I'm realizing that some of the required code could come from the work James is doing. Just getting this part to work would be interesting, and not crazy-difficult. The in-between stage in PharoJS is to still run in Pharo but access a DOM, etc. on a browser so you can get close to final debugging while remaining on Pharo. In many ways this is the most difficult part of PharoJS and would be the most challenging part for PharoJVM. Note that PharoJS (like Amber) doesn't attempt to have perfect fidelity with Smalltalk semantics (for example the numeric stack , dates, collections, morphic, etc. have Javascript semantics or don't exist). I would anticipate that PharoJVM would also have some non-standard semantics.

Any opinions? Would this be useful to people other than me?

[James Ladd]

Hi Dave,

Thanks for the suggestions.

Redline targets the Jvm for a couple of reasons (which I won't go into) but is also targeted at enabling people without Pharo to develop in Smalltalk w'out the barrier of changing IDE's. Yes I think Pharo is amazing and the IDE probably the most advanced in the world. However learning it is a barrier to those who use other tool chains.

Long term I hope that we will have Smalltalk on the server side and the client be it in a browser or command line.

Please continue to follow along and make suggestions - it does shape my thinking 

Sent from my Commodore 64

--

[Matt Selway]

Although what is more foreign, an annotation in the method that says <primitive:10> or some code written using the JVM receiver?
Just have to get the abstraction level of the JVM receiver right ;-)

[James Ladd]

Good point 

<primitive: 10>

Is polluting the source file but it is also v succinct.

The JVM receiver is more verbose but can also be put behind a method. 

I'm sure I'll just use the JVM approach as it w also serve as a guide for people wanting to build adaptor manually for Java classes 

Sent from my Commodore 64

[James Ladd]

I'm wrestling w what to do next as I want to do things that show working progress over things that might be used later for example the JVM object which by itself is fine. It if nothing uses it it prolly doesn't need to be there right now.

I know that one of the very first expressions in any Smalltalk can be a subclass: message to a receiver like Object.

So I'm leaning towards the resolving of that. Ie: looking up Object and if necessary compiling it. 

Thoughts?

Sent from my Commodore 64

[Matt Selway]

Well, one of my necessities is the Java Adapter, and if that depends on the JVM object then you need to work on that ;-)

But getting basic classes compiling is good too :-)

Since I've been looking at some of your old code more over the weekend I think I have a greater appreciation now for how much infrastructure goes into just getting the basic things going, e.g. with the Context objects and all sorts. How much of that needs to be there are the outset? If you need all of that infrastructure I would have thought the next step was clear, or are you trying to think of a way around it?

[Apokalypse Software Corp]

My own needs are to write code in the Smalltalk syntax that will compile to class files that integrate to the Java8 or Android SDKs.

[James Ladd]

That is going to happen. Watch for the next push to master 

Sent from my Commodore 64

[Apokalypse Software Corp]

Oh, believe me I am! I'm looking forward to it.

And once I get a better grasp of its structure, I hope to help you speed its development.

Alfonso Guerra
Founder/CEO
Apokalypse Software Corp

@Huperniketes
(626) 667-4285

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redline Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redline-smalltalk+unsubscribe@googlegroups.com.

[Angelo Schneider]

Regarding your comments about Jython: people use it to script Java Applications, may it be desktop applications or server applications on a backend. I think you completely missed its purpose: a Scripting language that completely integrated into the Java ecosystem and can access everything from the Python ecosystem.

And there are millions of people using it. I myself used it during the last 10 years in plenty of projects, many of the have an install base going into the thousands or have thousands of users.

[James Ladd]

Sorry if you felt I was negative to jython.

It is a great language 

Sent from my Commodore 64

On 18 Mar 2019, at 1:40 pm, Angelo Schneider <angelo.s...@gmail.com> wrote:

Regarding your comments about Jython: people use it to script Java Applications, may it be desktop applications or server applications on a backend. I think you completely missed its purpose: a Scripting language that completely integrated into the Java ecosystem and can access everything from the Python ecosystem.

And there are millions of people using it. I myself used it during the last 10 years in plenty of projects, many of the have an install base going into the thousands or have thousands of users.

--

[Matt Selway]

I am not 100% sure where this came from Angelo?

Looking at the history of this thread the only mention of Jython is from Dimitris Chloupis who was basically critiquing the idea of implementing languages in the JVM as something that is not strictly necessary as there are other means of integrating across languages. Jython was used as an example in a discussion about why James was wanting to implement Smalltalk on the JVM. The point of having a scripting language inside a Java application is one use case that potentially counters his argument but not all of it.

Considering that Jython does not appear to have a release newer than 2.7 (back in May 2015), according to jython.org, and that it does not support Python 3 I would say that Dimitris' argument about alternative implementations having a smaller user base than the core implementation seems warranted. (Also supported by the fact we do not have huge hordes of interested parties offering support to get Redline into a production state ;-) )

Also, as far as I am aware, Jython cannot access everything from the Python ecosystem as there are numerous incompatibilities (as there typically are in all alternative implementations).

Maybe I am missing some context that prompted you to reply to such an old thread Angelo? 

Personally I think people should use whichever language and implementation meets their requirements. To me Smalltalk on the JVM would meet my requirements. :-)

Now if only I had the time to keep contributing to Redline... :-|

[Angelo Schneider]

Hi,

if understood him correctly, his argument was: no one uses or needs Jython, because instead of programming in Jython on the JVM, you are better of using Python or CPython.

The use case for Jython however is scripting Java applications and not „I want to have a Python on the JVM“. As I pointed out I know dozens of software projects which are in Java and use Jython as scripting language, most often via JSR 223. (Scripting language in the sense of configuration, error checking, automation of user interaction, automated UI tests etc.)

Jython can use all of Python unless it is a C-extension or written in CPython. Java classes can inherit from Jython and Jython classes can inherit from Java classes. It is not 100% transparent as you have to glue them together by instantiating a Jython interpreter.

Smalltalk on the JVM would be a killer if it had an image. There once was one - well the company still exists, but their Smalltalk is no longer image based Exelent or something was the name.

Hope that helped :D

[Matt Selway]

Yeah, fair enough. I've used Jython myself in exactly that way. The fact it is no longer maintained though kind of speaks for itself and I wonder if its use in that context will start to drop off (if it hasn't already) as there are plenty of other JSR 223 compatible scripting languages. Some may even integrate better than Jython, e.g., Groovy.

I had a look but couldn't find the company you mentioned (Exelent?). But I did come across some work that was done in 2014 where some people implemented a JVM in Smalltalk/X

Wrong way around for what I want but I found it interesting :-)

Cheers,

Matt

[picoVerse]

You seem to be describing GNU Smalltalk