Trying to test some code in Pharo 2.0 and it depends on BlockContext which was dropped, what can I do?
You can download Pharo 4 and run Magritte 3 and Seaside 3.1, as that are the stable versions. The major change in Magritte 3, introduced and explained early 2012, is the moving of the descriptions to the instance side, and renaming description to magritteDescription. You can find sample code of Seaside & Magritte in a QCMagritte image you can download from CI, in addition to the plain magritte builds
Otherwise, just check the pharo, seaside and pier mailing lists of 4 years ago and the monticello repositories to see what changed. There have been lots of little changes because of the improvements in Squeak and Pharo in the past 4 years.
If you need to use Magritte 2 to migrate legacy code you might want to take a look (with Pharo 5) at my experimental MonticelloProjects code on Smalltalkhub. That builds a data structure of all source code in the Monticello packages in a project repository, allowing you to more easily see what changed when.
Related
Is Rebol 3 really different from Rebol 2 and Red-Lang. Is it finished ?
I was in the same boat as you before, hopefully, things are much clearer now. (Can't add to that one as it is closed)
As for finished (usable in production), only Rebol 2 is stable and mature (I myself use it, having only started a few months ago)
In order of easiest to hardest to get started:
Rebol 2:
Pros:
easy to get started (single binary)
stable, mature, full featured
has view (GUI)
lots of documentation
examples at rebol.net
lots of compatible libraries at rebol.org
has a large user base (still!)
Cons:
no active development (version I use is from 2011)
deployment is harder (need commercial SDK for native binaries, but can work around)
no native gui (might not be a problem)
Red:
(based on Rebol 2)
(community on gitter.im)
Pros:
easy to get started (single binary)
dead simple deployment (native binaries)
has native GUI (view and draw, still in development)
active development
Red/System (low level actual alternative to C, it is written in itself/self-hosted)
Cons:
documentation work in progress
not everything is working
small chance of breaking (due to being in alpha)
Ren-C:
(based on Rebol 3)
(community here on stackoverflow chat)
There are many branches of rebol 3:
This question gives a better overview. I chose "Ren-C" because it seems the most actively developed
Note: I haven't actually used "Ren-C", but only other rebol 3 binaries, so refer to the other questions and take this with a grain of salt, but it should be pretty similar to Red in terms of development and community
Pros:
more experimental than red?
active development
written in c/c++
other Rebol 3 (GUI) branches use it as upstream
these GUI versions are used commercially and in production
Cons:
more experimental than red?
harder to get started (compile from source)
written in c/c++
documentation?
based on rebol 3 so less compatible with rebol 2(?)
(actually, there seems to be a porting guide)
would probably be eventually merged into red(?)
As far I know, R3 isn't finished & has bugs. I don't think anyone works on Rebol 3 using that name.
HostileFork & other people are working on C implementations, named Ren/C as far I remember.
Ren/C & Red is work in progress - anything can change.
All 4 languages are very similar but you will find some differences from time to time.
For example:
in Rebol 3 request-file returns file not block of files as in Rebol 2
you can make "a function, making all words found in body local" (I think
Rebol 3 and Ren/c has something like this too)
they are working on parse, so you can expect something "better"
We know all that JGraph is a very powerful graphic library and now we are in version 6 (JGraphx).
Me I have an application (by the way I am newbye in JGraph) coded in JGraph 5 and I want to migrate it to Graphx.
Is there any tut to know what is the main differences between these two versions?
That migration, is it easy to do (in general)?
JGraph (the last version of which was version 5) and JGraphX (which was originally going to be called JGraph 6) are completely different code-bases. JGraphX was a complete rewrite from scratch, which is why we made the naming change to avoid the idea you could upgrade from 5 to 6.
So no, there is no migration route, you'd need to re-write your part of the application that interfaces with JGraph(X).
I was just looking on nhforge and saw the most recent release of nhibernate 3.0 is the alpha 1 release. Is that the most recent available binaries, or did I miss them?
Also, is nhiberante 3.0 solid enough to use in a production environment. Is anyone currently using 3.0 for development?
I am beginning to develop a new project and was wondering if I should stick to 2.12 or if it safe to move onto 3.0.
Thank for any thoughts.
EDIT -
I just found the following web post - http://www.infoq.com/news/2010/08/NHibernate-3.0 - which contains the following -
"NHibernate has reached version 3.0 Alpha 1, and is “rock solid”, according to Jason Dentler, author of the upcoming book "NHibernate 3 Cookbook" from Packt Publishing, and interviewed by Scott Hanselman. Dentler also said that even if it is an alpha release, NHibernate 3 is already used in production."
NHiberante does not have an instable branch. The code in the trunk is stable, but it is not feature complete until released. There can be issues in new features, but no issues in existing features. You can use the NHiberante trunk in production. Thousands of people do it already, you won't be the first one. The version in the trunk is more stable than the alpha binary release, because it contains bug-fixes. For NHiberante the rule is: The newer, the more stable.
"ready for production" is hard to answer. I suppose since it's alpha, you can simply say "no".
However, I am using it in a small project that is in production with no issues at all. I am quite impressed with the quality and "solid-ness" for an alpha release. Note that I have much of the code using nhibernate covered with integration tests, so my confidence is pretty high.
I'm writing a small free tool. It's currently in Beta testing using .NET 3.5 but there's at least one aspect from .NET 4 I'd like to incorporate.
So, is it jumping the gun a bit to release .NET 4 based software?
Thx!
Wait till atleast the public release of .NET 4.0 before releasing anything other than early beta software with it.
I'm excited about alot of the new stuff too, but beta software built on a framework that is itself in beta is a recipe for disaster if you ask me.
Writing code for 4.0 might make sense. Releasing for general consumption prior to its official release seems foolish to me. Minor changes in 4.0 between now and the official release could cause your code to break. It would likely be easy to fix, but until you do your users are mad at you for putting out (what appears to them to be) a buggy program.
I read somewhere that VS2010 comes with a go-live license, meaning you can. Not sure I would, though. (See other answers...)
Well, you'd be forcing people to download and install Beta software. People may be reluctant or even unable to do this so, if nothing else, you're limiting your audience.
Also anything built with the Beta software isn't guaranteed to be compatible with the final released version.
I wouldn't go for the full framework, but including libraries like the CTP for the Task Parallel Library if your application is heavily multithreaded would be OK since you can just ship the .dll with you application and your users won't have to download anything. However, even with the TPL I would watch out, it's quirky and can slow your algorithms by an order of magnitude on things that should seemingly run just fine. The CTP is already over a year old though.
I'm migrating the data layer of our application to NH version 2.1.0 (from 2.0.1) and noticed the use of LinFu. I discovered that framework and want to use it in other pieces of the application, especially I want to use the LinFu.Reflection.dll, which requires a reference to LinFu.DynamicProxy and here comes the trouble, the 1.0 final version of LinFu that I can find on google.code is not the same version used by NHibernate itself. Do I need to rebuild NHibernate.ByteCode.LinFu.dll changing the reference to the available version? If not, what else?
I have faced the same problem a few days ago. There's a tool named ILMERGE that merges .NET DLL-files, and that way you should be able to have several versions of the same DLL in your application.
Unfortunately I haven't tested the tool yet, I didn't get around to it, but I'll test in the next week.
But Rhino Mocks for example, has a binary with all dependencies included: http://ayende.com/projects/rhino-mocks/downloads.aspx, so it seems doable.