Interrupt script not shell

[nickl-]

You did it!!! Bloody marvellous it all works like a charm! Well done bro!!!!!

Everything works!!! Whoop whoop!!! .... if you use beanshell HEAD that is

It was a real mission to try and merge my old repository and commits with the latest updates upstream, I decided to just pull a fresh repository and start over. When I tested again it wasn't working =( but I vas sure it was working before, then I noticed you are still using v 2.0b5

I can't tell you why it's not working, I am more surprised that you are actually using that version at all. You probably never tried to build master?!?!? It's broken dude!!!! If I recall more than 70% of the tests were failing but even if you disabled the tests it won't build without problems. It's not even intact the latest release of beanshell.

Somewhere before they were approached to go into apache incubation, after which a whole bunch of fixes were applied to the source code, another team of developers forked the repository and went their own way with beanshell2, you are probably better off using that version it is far more stable.

I have spent the last 6 months merging the two forks, beanshell2 made many noteworthy fixes over the course of 2 years which are simply crucial but at then there were other additions made during the apache intake not presently available in beanshell2. It was crystal clear, if I wanted to see any improvement with beanshell I will first have to merge the two branches or it will become an impossible task if I don't. Took the best part of 4 months and was not much fun.... but it is done.

So also don't decide now to go and start using beanshell2 just because there is a release, everything is already included here. Over the last 6 weeks development was more satisfying, we've made a lot of progress but it's still been conservative, fixing or completing unfinished implementations or aiming to satisfy existing test cases. I can't wait to be done with this phase so we can get to the really fun stuff.

I have included the dependency change to use the custom build development version and I hope you will merge it but the choice is yours. Oh yes before I forget everything is ready to be committed if you agree, it is not like last time. I don't want to make things difficult for you but I am confident you shouldn't have any problems to pull the repository and build it with mvn install using either JDK 8, Java 9 or Java 10. All the tests will pass as well no sweats. Once it's installed to m2 you won't even notice it anymore. =)

There is no point for me to use the old version, I need to sort out the final issues in the latest version. I don't know how many issues because there are probably many still I haven't even seen yet. I am the only person testing it, which is why it would really help if you would use it and report any problems you discover.

It's been how many years since the last release so there is no need to rush a release what is waiting another month or three? What is more important for me is to me is that when we release and start promoting the new beanshell that it will be a product that we have confidence in and something that can start gaining trust from a community again. The last thing we need is releasing something and we start getting issues like "it doesn't compile with @SuppressWarnings" yip it is true, parser error and something I only saw yesterday. =/

I'm liking the jline more now that it is starting to come together, who knows perhaps this is ready by the time we have sufficient test coverage and we include it in the release. That would go a long way to gaining favour in the community once more. Anyway... went on a nice tangent there, thank you for listening. Let me submit and I will follow up with more details on the commits shortly.

Oh b.t.w mvn still can't find one dependency:

        <dependency>
            <groupId>ste.test</groupId>
            <artifactId>xtest</artifactId>
            <version>1.19.1</version>
            <scope>test</scope>
        </dependency>

I found the repo on your profile and managed to build it after hunting down several other dependencies those dependencies have. Not sure what it's used for because the tests don't even compile, perhaps it is because I am using version 1.20.1-SNAPSHOT... just thought you should know.

[nickl-]

Found the way to clear screen with jline, removed the clear screen escape sequence.

Added the ; for blank lines again, as it turns out ; is a valid node EmptyStatement. It gets ignored by the parser. Beanshell correctly detects we are in a block and refrains from sending the prompt again. Your fix with letting jline use an empty prompt now protects the prompt and it doesn't wipe the line anymore.

Everything was already there to implement the Ctrl C fixes for #2. The bsh.setExitOnEOF is to prevent BeanShell from calling System.exit() and exiting the VM. The suggested way to interrupt the interpreter and force a EOF is to close the in Reader. This even gets beanshell to abort an infinite loop. By restarting the interpreter with the old interpreter as parent we maintain context and if beanshell didn't print the banner again you won't notice it was interrupted.

I updated beanshell HEAD beanshell/beanshell@e2ec870 to not print the banner if beanshell is interactive and has a parent and made the loops consider Thread.interrupted which gets them to abort quicker but the functionality still works without the updates.

I'll make a sample of my output again when I have a chance...

nJoy

[nickl-]

Added indicate interrupt by printing text "^C"

Here is a clip of the result: https://goo.gl/og6zU7

hmmm there should be a better way to show clips....

[nickl-]

Why do you want to type ^C?

We just print ^C (which is kind of standard I think, isn't it?) to show that we Ctrl + C was received.

I don't see why we would type ^C.

[nickl-]

SNAPSHOT means current build version... not a release.

If you make the version the SNAPSHOT version it is clear to everyone that it is the a build version an not a release so I would suggest sticking with that.

I added a road map to the README to show what needs to be done before release... we are still very far from a release. Not going to happen anytime soon.

[stefanofornari]

hi nick,

I am not sure I've got it... :|

Ste

On Sun, Jun 24, 2018 at 6:56 PM, Nick Lombard notifications@github.com wrote:

Why do you want to type ^C?

We just print ^C (which is kind of standard I think, isn't it?) to show that we Ctrl + C was received.

I don't see why we would type ^C.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/stefanofornari/BshConsole/pull/8#issuecomment-399770714, or mute the thread https://github.com/notifications/unsubscribe-auth/AACogie29F0FoBEOWQ5YQ_jS6QCpiYbuks5t_8SngaJpZM4UuShZ .

[nickl-]

Which part? if you mean the SNAPSHOT part?....

Maven only downloads a release once... it gets stored under $HOME/.m2 after download and any further requests are served locally.

When running mvn install the built jar files are "installed" to $HOME/.m2 any further requests for this version will be served from $HOME/.m2

SNAPSHOT is the maven releases indicator that this is a development build, ie not a public release. This is a clear indication to anyone looking for this version that it is not a release but a development build. They would then attempt to build this version, by obtaining the project from GitHub which has the correct _SNAPSHOT version as the current development version. It can then be installed to $HOME/.m2 from where any projects which has the SNAPSHOT version as a dependency can find it.

If you make a "dummy release", as you suggested, removing SNAPSHOT from the version number but not actually releasing the version publicly there is no way for anyone to know where this came from, or how to satisfy the dependency. Even getting the source project and building it will not satisfy the requirement as it will have SNAPSHOT to the version number.

This is why it is acceptable to keep the SNAPSHOT version number as a dependency.

Hope that makes more sense or please elaborate on what is still not clear.

[stefanofornari]

Hi nick, I was not clear on the other message:

"Why do you want to type ^C?

We just print ^C (which is kind of standard I think, isn't it?) to show that we Ctrl + C was received.

I don't see why we would type ^C."

(I know how maven works :) ).

Ste

On Fri, Jun 29, 2018 at 12:43 PM, Nick Lombard notifications@github.com wrote:

Which part? if you mean the SNAPSHOT part?....

Maven only downloads a release once... it gets stored under $HOME/.m2 after download and any further requests are served locally.

When running mvn install the built jar files are "installed" to $HOME/.m2 any further requests for this version will be served from $HOME/.m2

SNAPSHOT is the maven releases indicator that this is a development build, ie not a public release. This is a clear indication to anyone looking for this version that it is not a release but a development build. They would then attempt to build this version, by obtaining the project from GitHub which has the correct _SNAPSHOT version as the current development version. It can then be installed to $HOME/.m2 from where any projects which has the SNAPSHOT version as a dependency can find it.

If you make a "dummy release", as you suggested, removing SNAPSHOT from the version number but not actually releasing the version publicly there is no way for anyone to know where this came from, or how to satisfy the dependency. Even getting the source project and building it will not satisfy the requirement as it will have SNAPSHOT to the version number.

This is why it is acceptable to keep the SNAPSHOT version number as a dependency.

Hope that makes more sense or please elaborate on what is still not clear.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/stefanofornari/BshConsole/pull/8#issuecomment-401318663, or mute the thread https://github.com/notifications/unsubscribe-auth/AACogv4sVMxekv6PYI-dZSwFb4uk4REWks5uBgTCgaJpZM4UuShZ .

[nickl-]

My bad =) I knew it had to be one or the other...

^C is a prompt only, not valid grammar will cause parse errors if used as string. ^C is printed as a response to Ctrl + C just to indicate that the interrupt was received and being processed. Output not input.

Can't think of anything else to say about ^C =/ , do you have a specific question?

What's new with BSHConsole?

[stefanofornari]

news will follow... :)

Ste

On Sun, Jul 1, 2018 at 6:37 AM, Nick Lombard notifications@github.com wrote:

My bad =) I knew it had to be one or the other...

^C is a prompt only, not valid grammar will cause parse errors if used as string. ^C is printed as a response to Ctrl + C just to indicate that the interrupt was received and being processed. Output not input.

Can't think of anything else to say about ^C =/ , do you have a specific question?

What's new with BSHConsole?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/stefanofornari/BshConsole/pull/8#issuecomment-401582469, or mute the thread https://github.com/notifications/unsubscribe-auth/AACoglEowSJnlGDmhFMystQ57H9E6nadks5uCFHsgaJpZM4UuShZ .

[nickl-]

nailed it =D

good response....