Hello,
I prepared a pull request which seems to pass the build and address these issues. However I think that the build hook has not been set up to run automatically,
you can create a passing pull request without anything actually building.
https://github.com/eclipse/january/pull/50
I propose to merge change, once everyone agrees. In order for people to pick up January it is critical that we do not have xtext and form dependencies.
Later I propose to put a build hook on the pull request. This is done by asking for admin from eclipse webmaster and adding the hook on github. The build appears
to be maven, so there are various options for that in github J
Cheerio,
Matt
From: january-dev-bounces@xxxxxxxxxxx [mailto:january-dev-bounces@xxxxxxxxxxx]
On Behalf Of Matthew Gerring
Sent: 19 January 2017 10:20
To: january developer discussions
Subject: Re: [january-dev] Newbie using January
Hi Torkild,
I strongly agree with all the points you make. I do not think UI or xtext should be there and geometry only if it is generic and not pulling in eclipse bundles.
I think january is more useful and easier to pick up if it is just doing data operations, numpy-like, perhaps with some improvements to metadata such as has been suggested. I think it could be a hugely successful project
if doing just that and most of the serious prospective users are not interested in SWT/jface UI and xtext parts. Some significant possible adopters do not have RCP at all.
I think org.eclipse.january.geometry.* org.eclipse.january.form* belong elsewhere and agree with your observation. In addition Baha was quite vocal on this.
On 19 January 2017 at 10:01, Torkild Ulvøy Resheim <torkildr@xxxxxxxxx> wrote:
Hi all,
I decided to have a look at January to see if it would be useful in a project that I’m working on, so I started by looking at the code[1]. The immediate experience was not very good and I thought I should report on that, as I believe it can easily be improved.
I expected January to be a low level API for handling numerical arrays, and it is there, but I also find a lot of unexpected, high level stuff. Especially in org.eclipse.january.geometry.* where there appears to be UI, and there is the org.eclipse.january.form*
which references Eclipse ICE. Not to mention all the “xtext” bundles. This is all very confusing, and I actually know a bit about January and it’s history. I just recently had someone else looking at the code for the first time describing it similarly to me.
I realize this is a young project and it will take time to make it solid. Maybe one could start by adding a section to the README describing what the various bundles do, and which one can safely ignore if one just want numerical arrays. I know there are some
tutorials out there, maybe they should be linked in?
If one were to do some real “clean up” I think it would be a good idea to make it intuitively clear what an API consumer should do. For instance I don’t think bundle a name should contain “xtext” because Xtext is used for the DSL, maybe replace “xtext” with
“dsl” in those. That way users understand what it is without knowing the details of the implementation. Also bundles that contribute to UI should contain “ui” by convention.
The org.eclipse.january.form* bundles appears to contain mostly ICE specific code. I don’t understand why this code is in a "NumPy clone". Maybe it should be moved to the Eclipse ICE repository?
[1] https://github.com/eclipse/january
I hope I was not too harsh & I’m looking forward to the January Workshop in Toulouse :-)
Best regards,
Torkild
--
Consultant & Senior Software Developer @ Itema AS -
http://itema.no
Eclipse Science PMC / Eclipse Committer
_______________________________________________
january-dev mailing list
january-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/january-dev
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
|
