reprap package success!!!

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Zach,

(Your email somehow crossed with my latest asking how it had gone for
you with Reprap.jar, so ignore that one.)

On Mon, 28 May 2007 19:10:22 -0400, "Zach 'Hoeken' Smith"
said:

> yes!! i finally got reprap to install and configure on linux!!

Joost confirms the Reprap.jar file also runs on Windows XP :-)

> 1. the program needs a few files other than the jar. the reprap
> properties file, a background STL, etc. i made the lib folder and
> put those files there and it worked fine.

The reprap.properties.dist is already folded into the .jar and seems to
be fine being accessed from there. The background STL is a bit more
work, because of an earlier unfortunate design choice (IMO) in the
STLObject library... I'm now hacking on that a little to resolve that
one, see my forum post for specifics. Basically choosing String types
to represent STL file locations makes it hard/impossible to cleanly
access such files that are within a .jar wrapper.

> 2. the java3d install doesnt exactly do everything. when i tried to
> run it at first, it gave me an error that said it couldnt load the
> STLLoader class. this was fixed by copying the lib/j3d-org-java3d-
> all.jar to my JRE environment. where is this file from and how do
> we make the normal install process include it?

Well... it's from the Reprap Subversion repository on SF... beyond that
I don't really know. Did a Reprapper hack it together at some point and
commmit it? Anyone who knows the origin of that file, please step
forward :-)

> my guess is i did something minorly stupid.

No, Joost and I see the same thing. At least there is a relatively
simple workaround for now.

> 3. the .jar wouldnt run in the sun 1.5.0 JRE, but works great in the
> sun 1.6JRE. we just need to update the documentation to reflect
> this.

I may be able to just redo my work under 1.5.0 to solve that. An
experiment for another day, low priority in my view since we have
"something that works" now.

> this is really rad. i'm going to try and run this .jar in mac and
> windows.

I'd love a report on how it goes on the Mac, I don't have easy access
to a Mac I can install stuff like this on (I have friends with Macs,
but they are arty types who might freak out at this sort of stuff on
their Macs!)

> hopefully we can get a nice cross-platform build process up and
> release the RepRap software at v1.0 in the next week. then we can
> just go from there.

Eeeek! We still need the "uses too much memory" issue to be fixed
before Reprap v1.0 will build all Reprap Darwin RP-able parts...
(which is kind of the whole *point*!) so maybe we can release a v0.9
without that, but IMO not a v1.0. I doubt I can solve that issue
within a week!!!

Jonathan
--
Jonathan Marsden
jmarsden@fastmail.fm

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Zach,

On Mon, 28 May 2007, "Zach 'Hoeken' Smith" said:

>> The reprap.properties.dist is already folded into the .jar and seems
>> to be fine being accessed from there. The background STL is a bit
>> more work, ...

> can we just keep it outside the .jar?

Better to keep the defaults inside the .jar, and allow for tweaking via
reprap.properties IMO.

> we should already just distribute a .zip file anyway.

Not a sane packaging mechanism really... what happens depends on where
it is unpacked, users unpack it and can't find the resulting files, ...
not good, becomes a support issue in a hurry.

We need an installer that puts files in a known place on each platform
and adds Start menu items that work, so end users install it and go
click click click to run it just like they run any other GUI app.
A working .jar is just a starting point for that.

> it makes changing that file easier too.

Not really. Edit your properties to point to a new file, and off you
go.

> plus, then we can put a README, license, start script, etc. there

Some of those will be platform-specific... let's do this right :-)

>> I'd love a report on how it goes on the Mac ...

> no-go. i think we're looking at the java 1.5 issue. macs dont have
> java 6 yet.

Then we should probably back down to 1.5.0 for cross platform
compatibility.

Jonathan
--
Jonathan Marsden
jmarsden@fastmail.fm

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Jonathan Marsden wrote:
> [...]
> Then we should probably back down to 1.5.0 for cross platform
> compatibility.
> [...]
>

This is an important point. What will be the minimum JRE requirement?
As of a few months ago, it also ran on 1.4.1 and I have been doing new
threading stuff with that compatibility in mind (a little extra work).
Are we going to officially ditch support for that now?

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Quoting Simon McAuliffe :

> This is an important point. What will be the minimum JRE requirement?
> As of a few months ago, it also ran on 1.4.1 and I have been doing new
> threading stuff with that compatibility in mind (a little extra work).
> Are we going to officially ditch support for that now?

Does a move to 1.5.0 present a problem (including extra work) for the
threading stuff? If so we should seriously consider restricting
ourselves to 1.4.1.

If not, then I think we should decide primarily on the basis of how
easy it is for users. Are there platforms on which 1.5.0 won't run? I
guess not.

Also, we should ensure that we have as smooth an upgrade path into the
future as possible.

Of course, Java standards should always have been such that things
might become deprecated, but never disallowed...

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Simon,

On Thu, 21 Jun 2007, "Simon McAuliffe" said:

> Jonathan Marsden wrote:

>> Then we should probably back down to 1.5.0 for cross platform
>> compatibility.

> This is an important point. What will be the minimum JRE requirement?
> As of a few months ago, it also ran on 1.4.1 and I have been doing new
> threading stuff with that compatibility in mind (a little extra work).
> Are we going to officially ditch support for that now?

There seems to be use of enum stuff in the codebase now that won't
compile under 1.4.x, at least according to the Eclipse compiler/builder.
So I think someone (accidentally??) decided it is OK to use 1.5.0
language features already. We could (and perhaps should) recommend that
people use the latest JDK, but set things to compile classes that are
runnable in a 1.5.0 JRE. This way we get the benefit of newer compilers
with warnings for more deprecated stuff, etc. etc., but retain
portability to Macs.

My personal build.xml / build-user.xml is actually set this way now, but
I wanted to play with it a bit more before committing the change into
Subversion. For now I'm using a 1.5.0 JDK on both Windows and Linux,
since that is what the current Wiki docs recommend, and I want to test
the "officially approved" installation approach.

[Aside: We should also make sure we run fine in the latest JRE, because
soon (hopefully!) Sun will release a complete JRE under the GPL, and we
should probably encourage people to move to that once it becomes
available, for maximum replicability and future flexibility. ]

Unless there are platforms we care about that have Java 1.4.x but no
Java 1.5.x, I suggest a minimum JRE of 1.5.0 is acceptable and should be
made the official requirement. (JRE 1.5.0 exists on Windows, Linux,
Mac, FreeBSD and (Open)Solaris. That's probably quite enough platforms
to keep us honest about our portability goals!) If anyone knows of such
a 1.4.x platform we need to consider, or other reasons why we should
work to retain 1.4.x JRE compatibility, speak up :-)

Jonathan
--
Jonathan Marsden
jmarsden@fastmail.fm

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Jonathan Marsden wrote:
> Unless there are platforms we care about that have Java 1.4.x but no
> Java 1.5.x, I suggest a minimum JRE of 1.5.0 is acceptable and should be
> made the official requirement. (JRE 1.5.0 exists on Windows, Linux,
> Mac, FreeBSD and (Open)Solaris. That's probably quite enough platforms
> to keep us honest about our portability goals!) If anyone knows of such
> a 1.4.x platform we need to consider, or other reasons why we should
> work to retain 1.4.x JRE compatibility, speak up :-)
>

Anybody know about java on OLPC?

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

On Thu, 2007-06-21 at 17:49 +1200, Simon McAuliffe wrote:
> Anybody know about java on OLPC?

No go: Not enough memory.

There was talk from the OLPC folk at LCA2007 of using Java as the native
language now that Sun have opened it; currently they use Python.

Vik :v)

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

> There was talk from the OLPC folk at LCA2007 of
> using Java as the native
> language now that Sun have opened it; currently
> they use Python.

From what I've seen Python is a much nicer language than Java. It will be interesting to see if it supplants Java eventually.

Adrian Bowyer wrote:
> Does a move to 1.5.0 present a problem (including extra work) for the
> threading stuff? If so we should seriously consider restricting
> ourselves to 1.4.1.
>

No, moving to 1.5.0 doesn't present a problem at all. Doing some
threading/synchronisation stuff is easier in 1.5.0 so the extra effort
to make it compatible with 1.4.1 would have been unnecessary.

If we're happy that nobody wants to still run 1.4.1 I'm happy enough to
drop it. Lets be fairly certain nothing needs it though.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Vik Olliver wrote:
> On Thu, 2007-06-21 at 17:49 +1200, Simon McAuliffe wrote:
>
>> Anybody know about java on OLPC?
>>
>
> No go: Not enough memory.
>
> There was talk from the OLPC folk at LCA2007 of using Java as the native
> language now that Sun have opened it; currently they use Python.
>

That would be cool...

I've always imagined having a different distribution (jar file etc) that
is a cut down version of the application without all the graphics or
possibly with varying graphics capability.

The ultimate in cut down could be for the "bush reprap" which was the
ultra-simple concept where you don't have any external PC at all, and a
very simple embedded java processor directly in the reprap. Along with
two SD slots for storing and copying RepRap assembly files, you have a
minimal interface consisting of only several buttons and a simple
display. It would be so simple and appliance-like that somebody without
any computer knowledge could use it.

The OLPC version could be somewhere between the two extremes. I suppose
a starting point might be a command line version that just takes an
assembly file as a parameter and produces it without any of the bells
and whistles. Or a simple GUI that does essentially the same thing.
That would mean Java3D isn't even needed, which may simplify things a
bit. Or if it turns out we can run Java3D on the OLPC machines then we
could have the construction area, but just textual progress information,
which would greatly reduce the memory requirements.

I don't know how much memory we have to play with on them, but once we
fix the progress window to reduce the currently vast memory
requirements, maybe it would be feasible anyway (?).

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Based on [wiki.laptop.org] it seems Java on OLPC is at least somewhat doable, and those playing with it are apparently using 1.5.0. But Java is not part of the base OLPC software distribution at all, at present, AFAIK.

Jonathan