Open miscco opened 8 years ago
Hi This is my fault. I have rewritten a bunch of documentation and also the code has been changed but I havent done this on Github. I am new to this, so please forgive me. There are many recent fixes since November. How is the best way to proceed to get this on Github for updating. I have a .tgz file that has the whole updated source and xpp_sum files. How should I proceed?
Thanks
So the short answer is add new files via git add, update the existing ones and commit. You can also send me the tar and i make a pull request.
In the long term it might be beneficial to reorder the whole source tree, similar to what @tommie did in his fork of xppaut 7.0 https://github.com/tommie/xppaut
I am kind of inclined to do something like that in my free time to understand the code better
Ah, I've been meaning to file this bug. Thanks for doing so (and implicitly pinging me).
Nice to see the original source code is moving to Github!
@tommie, i will definietely start porting your changes from 7.0 to 8.0 once i have some better understanding of the code. Maybe exept for GNU autotools, as they are not really portable.
I am attaching the latest version xppaut8.tar.zip below. I am really happy to see people working on this as it has been a solo project for the last 25 years (started as a DOS program in 1991 or so)
There is a MAJOR issue for Mac OS El Capitan. The X11 stuff is really really slow and bad and I am not sure why since it doesnt happen on older versions of OS X, or on Linux. If anyone knows what is happening, that would be great. All the action is in main.c under the routines for xpp_events
Bard xppaut8.tar.zip
@miscco (not arguing, just asking) what do you need to do with the autotools that isn't supported? (I realize this is off-topic and should be discussed elsewhere. :)
@tommie Acutally, I just thought i remembered that the windows support is rather slim. I have to check that though
@Ermentrout I cannot thank you enough for that wokr, it has been and is still really inspiring. To what extend is xpp bound to X? Maybe something more recent like QT might be appropriate
All the GUI is in Xlib. At some point I wanted to use something else, but never had the energy to do it
Bard
@tommie I have to remedy the part about GNU autotools, seems that they are fairly easy to install with MinGW/Cygwin
@Ermentrout The file batch.tex for xpp_doc is still missing after i updated from your tarball.
Here is the batch.tex. Sorry about that bat.zip
Can someone tell me what to do with this message: (I do not want to add any commits, I want to ignore them as they are no longer relevant)
# thx
So if you commit locally, and you do not "git push" they do not appear in github. Therefore that message comes.
Now if you merged the last PR then you have conflict to resolve
Basically, this is the abyss you enter onceyou work with more than N=1 people and git :smile:
I do not even know which files were committed locally. As the most recent version is the one that I sent you, I do not want any of my local changes made. However, in the eventuality that I will make changes that I want to push, I want to "forget" these local changes whatever they are. Regrettably, I have alredy made a pull request to the new version so my local github directory will be up to date. Sorry for my obtuseness. Never worked collaboratively on a big software project.
So there are different ways.
The easiest would be to revert your local changes:
git reset --hard HEAD~3:master
That will remove any history of the last 3 commits done. It would be saver to use
git log
and get the SHA of the commit you want to go back to and do a
git reset --hard SHA1
If you are sure you want to revert to a remote origin/master you can also do
git reset --hard origin/master
batch.tex references an \includegraphics called DutchBoy.png, which is also missing.
Here is is. Sorry All of these are in the older version of xppaut7 and I forgot to put them in as they are a fairly recent addition
thx
Thanks for the quick reply.
Latex is complaining it can't get the bounding box for DutchBoy for me. Am I missing something? Should there be a .bb file, or are you using pdflatex directly to generate the docs?
pdflatex seems to work. The documentations is terribly out of date in many respects. This is whyy I added tree.tex (it has all the commands) and xpp_sum.tex (which describes ode files etc)
I keep these up to date. The doc really needs a thorough revision, but I just gavent had time and wanted to get xpp8 out as it is much better.
Nice. Added batch
and DutchBoy
, plus switched to pdflatex
in my refactoring repo and now the docs build nicely: tommie/xppaut@f3666d8
@tommie As you already did a lot of refractoring, do you intend to carry that over to xppaut8? I would like to have a look at the GUI
Dunno. My end-goal is to separate maths and GUI. Then upgrading to a GUI toolkit. Right now it's very entangled. Would also open up for headless batch mode and acting as an HTTP server.
The most useful difference with the refactoring from a hacking perspective is the use of header files to ensure type-safety across files. I've found some memory issues with that (array sizes), and more using Valgrind.
I'll apply the xppaut 8 diffs if they are not too difficult to patch in. I should have a pristine vendor tag to diff from. It seems I didn't push that to Github, though. Otherwise I'll continue on 7.0.
However, I'm doing this for fun, so progress is very spotty. I also don't have a use for XPPAUT. :)
(I might also remove the current Github repo and fork this instead to get a back-link.)
The difference between 8 and 7 is quite big with regard to AUTO - the auto and related stuff is all completely revamped as I upgraded to a new version of AUTO. As you noted, the code/GUI are hopelessly entangled. I have a version without AUTO that has no gui and this was used to port the non-auto part to iOS. The batch server is pretty much already set up in the current version as you can run it with many new command line args that do not require any GUI. For example, once you have the ODE file, you and change paraneters, integration methods, etc very easily from the command line with no GUI. Maybe that is the way to go, but it will not work with the AUTO part as, there, AUTO is supposed to be highly interactive. (There is already a GUI-less AUTO available)
@miscco: Looks like @sanjayankur31 has started a refactoring using cmake.
So I think we'll end up with many versions.
Hmmm. well that would not be optimal, I am agnostic about the different possible GUIs, but the main compute code and parsers, I think should be uniform. The main differences between 7 and 8 are that there are more command line features, a new version of auto, and a few more options for communicating with external libraries like CUDA and C. Maybe I should try to separate the GUI out (I did this many years ago when I had a windows only version using their API, but never kept that up) For me, the main reason to overhaul the GUI is because it really slows up on the new Mac OS (El Capitan) and the reasons for this are completely obscure to me. The other reason to update the GUI is so that there editable text, cut & pase, better window handling and more intelligent updating of things like resizing and exposure.
Yepp. :) As long as people enjoy what they are doing, having many versions isn't bad. But I think you'll get some help on the official code now that it's on GitHub.
The diff to v7 is fairly big, but most of it is definitely AUTO. I don't think I'll be upgrading mine to v8 since I'm only doing it for the coding exercise, unless someone else wants to build on that work.
The tar file has irrelevant file mode changes that I ignored then importing here: tommie/xppaut@74520c3
cool . That is fine with me. 7 is still prerry much complete except for AUTO
@tommie, i think i migh want to boorow your work, but i dont know how much time i will have
Should be fixed in #6
Hiya! Sorry I couldn't get to this earlier. The reorganising using cmake is quite complete actually. It builds and works, at least on my Fedora system. Unfortunately, I haven't access to a mac or windows system (I don't use them at all).
https://github.com/sanjayankur31/xppaut/tree/wip-cmake-new
I was trying to "unbundle" the sundials part, but after a quick conversation on their users mailing list, I'm not quite sure if it's as simple a task as I'd expected. Sundials don't have a proper SCM any place, so it's really really difficult to pin point what changed and when.
@sanjayankur31 Thats really nice.
@Ermentrout As stability is generally a concern, could you create a development branch, that then accumulates all those little changes. that would have the advantage, that we can experiment a bit with the code, without breaking userspace.
Hi,
the section about command line inputs is missing in this version of xpp_sum.tex