Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REPL does not read version from fregec.jar? #33

Open
Ingo60 opened this issue Aug 15, 2015 · 2 comments
Open

REPL does not read version from fregec.jar? #33

Ingo60 opened this issue Aug 15, 2015 · 2 comments
Assignees

Comments

@Ingo60
Copy link
Member

Ingo60 commented Aug 15, 2015

I just downloaded Frege REPL 1.2.1-SNAPSHOT, and changed the fregei shell script so that it uses frege3.22.525-g704b834.jar.

However, the version displayed is still 424:

ingo@freguntu:/tmp$ frepl  # just alias to fregei
/home/ingo/bin/java
Welcome to Frege 3.22.524-gcc99d7e (Oracle Corporation Java HotSpot(TM) 64-Bit Server VM, 1.8.0_40)

frege> :version
3.22.524-gcc99d7e

frege> 10-2*3
4

But because it outputs the correct result from the expression (instead 24) means that it actually uses the 525 jar.

I think it would be better to report the actual version from frege.Version. For, when we get a bug report, it'll be hard to establish which frege jar is actually used otherwise.

@mmhelloworld mmhelloworld self-assigned this Aug 15, 2015
@mmhelloworld
Copy link
Member

REPL does read version from frege.Version.version but the problem seems to be that since it is a constant on the Version module, Java compiler is basically inlining the constant value in FregeRepl module. Thus it ends up as a constant in the class file and it doesn't use Version.version at runtime.

This is clear from the bytecode of FregeRepl module:

javap -cp "./lib/*" -verbose frege.repl.FregeRepl | less

And the relevant bit of bytecode:

169: ldc_w         #323                // String Welcome to Frege
172: ldc           #204                // String 3.22.524-gcc99d7e

The StackOverflow threads, this and this, touch upon this problem and the solution seems to be adding an intern() call on the version string so that the compiler doesn't inline the constant.

@mmhelloworld
Copy link
Member

@Ingo60 do we have to do anything for this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants