Re: [Plplot-devel] git blog
Hi, Alan, I don't know of any such option, but perhaps a newer version of git has added this feature? Another option might be to "go rogue" and use the patch utility to apply the patch in the working copy, then "git add" and "git commit" manually. Maybe patch will be able to ignore the whitespace changes? Wish I had a better answer for you, Dave On Sep 10, 2015, at 4:46 AM, Alan W. Irwin wrote: > I have a question for the git gurus here. > > I just ran into difficulty with git apply (as wrapped by git am) > because the patch file was created before a styling change that > changed whitespace not only for the context lines but also the > single line (in this case) that was replaced by several lines. > > "git help apply" says the following: > > --ignore-space-change, --ignore-whitespace >When applying a patch, ignore changes in whitespace in context lines if > necessary. > > As documented this does work for style changes for the context lines, but not > the > replacement line(s). > > Is there some other option (perhaps not yet documented in git help) > which is the equivalent of --ignore-all-space, i.e., ignore whitespace > changes in replaced lines as well? > > I also tried patch --ignore-whitespace --dry-run to see if that would > work, but it did not since from that documentation a run of whitespace > is treated effectively as a single blank, and in some cases styling > adds blanks where there were none before. > > In the present case, I worked around the issue by editing the single > replaced line to match the new styling, but that method is cumbersome > if there are a lot of replaced lines, and a git apply option to simply > --ignore-all-whitespace in both context and replaced lines would be > much better. Is such an option out there for git apply? > > Alan > __ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __ > > Linux-powered Science > __ > > -- > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140 > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot 6 and git
Hi, Phil et al., On May 23, 2015, at 1:23 AM, Phil Rosenberg wrote: I could make one last alternative suggestion. We could have a private git site. This could have separate 5.8 and 6 branches. Then when we are ready to merge we can rebase the branch, push it to our sf repo and close the site. I'm not an active PLplot developer, just a lurker on the list, so feel free to disregard my comments. I like your suggestion for having separate 5.8 and 6 branches, but I wonder why people feel the need to keep them in a separate (possibly even private) repository. Why not just create the plplot-6 (and related) branch(es) in the public repository right now (leaving master as the de-facto plplot-5.8 branch)? If it is motivated by a desire to adhere to the rebase-only workflow, yet it causes you to setup private repositories and/or email multiple (possibly conflicting) patches around, then you're not really taking full advantage of what git does. Maybe it's time to re-examine the original motivations for the rebase-only workflow to see whether they carry the same weight as before. I think the migration from svn to git, both technically and mindset-wise, was one of the major reasons for choosing the rebase-only workflow. Maybe that's not so important anymore? A fairly significant advantage (IMHO) to keeping 5.8 and 6 development in one repository is that it makes it much easier to diff between versions. Just some thoughts, Dave -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Rebase workflow
Hi, Phil.
On Feb 22, 2015, at 4:52 AM, Phil Rosenberg wrote:
In addition to Alan's suggestion, another approach would be to setup a
local bare git repo that all your local machines could push/pull to/from.
I tried this. As soon as I rebase a branch I am no longer able to push
it to the local bare repo because all the changes made since the last
push no longer exist and are replaced with new ones with different
guids.
I started to write that I don't understand why you are not able to push to the
local bare repo and I created much of the text below. In doing so, I realized
the problem you are having. You are absolutely correct that you cannot push a
rebased branch to the original branch because the commit IDs have changed. You
will need to push the rebased branch to a new branch. There are two ways to do
this. One is to create a topic-rebase branch from the topic branch, rebase
the topic-rebase branch and then push the topic-rebase branch. The other
way is to rebase the topic branch and give it a new name when you push it to
the local bare repo. Below I show the first option, which I prefer because it
keeps the original topic branch intact.
1) Start from the master branch that has commit C as the current HEAD:
A--B--C -{master, origin/master}
2) Create a topic branch and create commits d and e on it:
A--B--C -{master, origin/master}
\
+--d--e -{topic}
3) Push topic to your local repo:
A--B--C -{master, origin/master}
\
+--d--e -{topic, local/topic}
4) Using other local machines, push/pull the topic branch to/from the local
repo and it ends up with additional commits f and g:
A--B--C -{master, origin/master}
\
+--d--e--f--g -{topic, local/topic}
5) Fetch from origin, find that some else has pushed commits X and Y to master,
and fast-forward your master to match it:
git fetch origin
git co master
git merge --ff-only origin/master
A--B--C--X--Y -{master, origin/master}
\
+--d--e--f--g -{topic, local/topic}
6) Create and checkout a new topic-rebase branch that is based on the topic
branch:
git co -b topic-rebase topic
A--B--C--X--Y -{master, origin/master}
\
+--d--e--f--g -{topic, topic-rebase, local/topic}
7) Create and checkout a new topic-rebase branch that is based on the topic
branch:
git co -b topic-rebase topic
A--B--C--X--Y -{master, origin/master}
\
+--d--e--f--g -{topic, topic-rebase, local/topic}
8) Rebase the topic-rebase branch onto the new master, which will create new
commits d', e', f', and g' that correspond to commits d, e, f,
and g. These new commits will contain the same changes (assuming no
conflicts with commits X and Y) as their counterparts and have the same log
messages, but each commit will have different parent (e.g. d' has parent Y
while d has parent C) and probably different trees (due to changes from X and
Y) so they have different commit IDs. This step could involve conflicts that
need to be resolved, but this assumes that wasn't necessary:
git rebase origin/master
A--B--C--X--Y -{master, origin/master}
\ \
\ +--d'--e'--f'--g' -{topic-rebase}
\
+--d--e--f--g -{topic, local/topic}
9) Push topic-rebase to the local bare repository:
git push local topic-rebase
A--B--C--X--Y -{master, origin/master}
\ \
\ +--d'--e'--f'--g' -{topic-rebase, local/topic-rebase}
\
+--d--e--f--g -{topic, local/topic}
10) Other local machines can fetch from the local bare repo and they will get
the topic-rebase branch and all of its commits. Everything looks good, time to
share with the world!
11) Fast forward master to topic-rebase:
git co master
git merge --ff-only topic-rebase
A--B--C--X--Y -{origin/master}
\ \
\ +--d'--e'--f'--g' -{master, topic-rebase, local/topic-rebase}
\
+--d--e--f--g -{topic, local/topic}
12) Push master to the origin repo:
git push origin master
A--B--C--X--Y--d'--e'--f'--g' -{master, topic-rebase, local/topic-rebase,
origin/master}
\
+--d--e--f--g -{topic, local/topic}
Hope this helps,
Dave
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git blog
Thanks, Arjen, I didn't know that Tortoise SVN supported that. Now I'll have to tone down my praise of git add a little! :-) Dave On Feb 3, 2015, at 2:50 AM, Arjen Markus wrote: Hi everyone, In defence of SVN – couldn’t help myself – the tool (Tortoise SVN) I have been using for years now to deal with SVN has given me much the same degree of freedom, as it presents a nice dialogue to select the files and edit the commit message etc. As my first experiences with git were via a command-line tool (that is not the problem) in an unfamiliar shell (that is a problem), I was far less enthousiastic than most of you. But I am beginning to understand the way git works – at least vis-a-vis our rebase workflow – and that has made things much clearer. Regards, Arjen -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Saturday, January 31, 2015 7:15 PM To: David MacMahon Cc: Arjen Markus; PLplot development list Subject: git blog On 2015-01-30 10:22-0800 David MacMahon wrote: I first thought that [git add] was a weird and annoying extra step, but I have grown fond of this capability as well. I often find myself with several files to commit, yet the changes are not all related. Git makes it easy to commit only some of my modified files, so I can make each commit contain just the changes that I want to group together. Thanks, Dave. Your above comment perfectly captures my own reactions to git add over time. I have not yet tried the -p (--patch) or -i (--interactive) capabilities of this command, but they do seem quite powerful. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Problem pushing changes to the repository
Hi, Arjen, On Jan 30, 2015, at 1:15 AM, Arjen Markus wrote: the thing that has frustrated me using git is the fact that unlike subversion and most other revision control systems I have used, things are arranged in small steps. This is a difference, to be sure, but I have grown to appreciate that git provides more fine grained control. For instance: “git fetch” only fetches the changes into the local repository, it does not change the checked-out files. That happens in the “git merge” step. Isn't that great! :-) I generally prefer to fetch and merge in two distinct steps so I can examine the newly fetched changes before merging them. That's harder to so with svn (lots of rdiff and rlog). (there is also the matter of explicitly adding files to the commit step – another difference with subversion). I first thought that was a weird and annoying extra step, but I have grown fond of this capability as well. I often find myself with several files to commit, yet the changes are not all related. Git makes it easy to commit only some of my modified files, so I can make each commit contain just the changes that I want to group together. There's even git add -p which lets you pick and choose which changes within files should be added to the commit. Talk about fine grained control! Dave -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git blog
Hi, Alan, On Jan 30, 2015, at 2:43 AM, Alan W. Irwin wrote: So instead of either set of commands above you should be following the detailed recipe which is git checkout master git fetch git merge --ff-only origin/master FWIW, the pull command also accepts --ff-only. I have setup a puff alias for this (PUll --FF-only = PUFF): git config --global alias.puff 'pull --ff-only' Then you could do: git checkout master # if not already on master git puff origin/master I also have a ff alias for fast-forwarding: git config --global alias.ff 'merge --ff-only' Then you could do: git checkout master # if not already on master git fetch # examine changes git ff origin/master Enjoy, Dave -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git blog
On Jan 30, 2015, at 3:56 AM, Alan W. Irwin wrote: git log --name-status Nice! I didn't know about --name-status. I've always used --stat. Same idea, slightly different output. Dave -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git blog
Hi, Alan, On Oct 22, 2014, at 6:17 PM, Alan W. Irwin wrote: Today I wanted to discover the author, commit id, and the date for a commit that created a particular line in a file (the restore_cmap1() line in examples/python/xw08.py which has no C counterpart). After a bit of searching I discovered the git blame command which did exactly what I wanted. It sounds like git blame was the perfect tool for this job. Another similar tool is git log -S. $ git log -Srestore_cmap1 --oneline examples/python/xw08.py d7db05b Revert to using fixed examples and instead have a include file which adds the correct import statements for Numeric / numpy. This also allows the file to define functions missing from Numeric, e.g. isnan. 32686ad Port python bindings to use numpy instead of Numeric. Currently numpy support is disabled. To enable it use -DHAVE_NUMPY=ON on the cmake command line. 8bb973d Add routine to restore cmap1 to default (so that subsequent examples that use cmap1 such as xw16 still continue to have default cmap1). There's also git log -G which takes a regular expression. See git help log for more details. For a single file, git blame is generally preferable (though it can be slower), but for multiple files/directories git log -S is great. I was concerned that might create a different PostScript file result for Python, but since restore_cmap1 call has been there since 2002 with no issues like that, I have to look elsewhere for the source of the recently introduced one-line diff I am getting between the plsurf3dl Python and C results for example 8. There's always git bisect... :-) Dave -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] An issue with the ps device driver that is extraordinarily sensitive to rounding
Hi, Alan, Thanks for the interesting read! On Oct 23, 2014, at 3:49 PM, Alan W. Irwin wrote: So back to figuring out this ps device driver issue that apparently emits isolated M commands that come or go due to sensitive rounding issues that only occur in the 14th or later decimal digit of the floating-point quantity. This is just a shot in the dark, but is it possible that this is supposed to be a closed path and one implementation gets the first/last points close enough so no closing segment needs to be drawn while the other implementation gets them not quite close enough so a closing segment is drawn? This assumes that the close enough test happens at a higher precision than the drawing commands which rounds these not quite close enough points to exactly the same point. Dave -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] URL syntax of POST method for contents of files?
Hi, Alan, On Sep 30, 2014, at 10:46 PM, Alan W. Irwin wrote: POST /rest/p/project_name/mount_point/title - creates or updates the titled page parameter text: page text parameter labels: comma-separated list of page labels From a one-line comment further on I can infer that for the PLplot wiki, the full URL corresponding to the above is https://sourceforge.net/rest/p/plplot/wiki I think curl will do what you need. Take a look at: http://curl.haxx.se/docs/httpscripting.html#File_Upload_POST To upload a foo.md file with wiki title Foo and labels whatare,labels (what are labels?), I think you could do: curl --form text=@foo.md --form labels=whatare,labels https://sourceforge.new/rest/p/plplot/wiki/Foo or something like that. Good luck, Dave -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] More discussion of our adopted rebase workflow
Hi, Alan, On Sep 23, 2014, at 10:41 PM, Alan W. Irwin wrote: On 2014-09-23 16:01-0700 David MacMahon wrote: Just to nit pick: [...] Your comment above caught this nit-picker's attention. :-) Takes one to know one! :-) :-) :-) What I was referring to (see README.developers) is we recommend each developer configure their local PLplot git repo using git config merge.ff only Maybe I'm just getting caught up on the semantics of the word enforcement, but I don't consider that client side enforcement. It requires developer intervention to setup and can be overridden via the --no-ff option. If that counts as client side enforcement, then you could just as easily consider a client side pre-commit hook to be client side enforcement. That also requires developer intervention and has a command line override (--no-verify). This command should stop merge commits of any kind for the local PLplot repo where it is run. This prevents (in the absence of --no-ff) the local creation of merge commits, but it does not prevent merge commits from appearing in the history. I agree one of the client-side merges tested by this configuration occurs just before the push in our workflow so you could claim it is just a pre-push check. However, I think it is a little broader than that. For example, if the PLplot developer made some mistake by doing a git fetch and merge or equivalent git pull from some random unofficial private PLplot repository that included merge commits by accident, my understanding is this configuration option would catch that issue before the local repo was contaminated by those merge commits. I think you are expecting too much from --ff-only. Running get merge --ff-only new_branch while on the master branch will prevent the creation of a merge commit if master cannot be fast-forwarded to new_branch. It will NOT prevent the fast forwarding of master to new_branch if any of the intervening commits are merge commits. git will happily fast forward master over any number of merge commits so long as master is an ancestor of new_branch. What could happen is that a PLplot developer starts with master that is up-to-date with sf.net and with merge.ff=only configured locally. Then the developer fetches a bunch of commits (that include merge commits) from a rogue repo. The rogue repo's build tests out OK, so the developer pushes the commits (including the merge commits) to the master branch on sf.net. None of this is prevented by --ff-only. With an suitable server side hook, the server side could reject the push, otherwise the public repo will end up with merge commits from the rogue repo. A client-side pre-commit hook could alert the developer to merge commits in the history, but that only fires if a commit is being done. A client-side pre-push hook could alert the developer to this situation before pushing, but that would happen only slightly sooner than a server-side pre-commit hook would reject things. Dave -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Exit calls and memory management
Hi, Alan, On Sep 22, 2014, at 12:37 PM, Alan W. Irwin wrote: You are much more experienced with git than me. However, I thought that rebasing a public branch was always a bad idea for the reasons I mentioned concerning disappearing commits. I am positive a number of resources I read when we were considering using a rebase workflow mentioned this drawback to that approach. I agree that rebasing any part of a branch that has been pushed is a bad idea. It makes things complicated/inconvenient for those who are following the branch. If they are right, then for rebase workflows like ours experimental branches should not be made accessible on public git repos since the bad choices afterwards are to rebase them periodically (which loses prior public commits) to keep up with master development or else become out of date with master. I can understand the desire for a nice clean linear history, especially since the code was just migrated from Subversion. Strict adherence to a rebase only workflow will definitely result in a nice clean linear history. Starting with a strict rebase only workflow requirement, the statement quoted above sounds reasonable, but the experimental branches should not be made accessible on public git repos part of it really sounds wrong to me. It makes me wonder whether a strict rebase only workflow is really best. Which means some other alternative for sharing experimental development topics must be used such as sending patches to this list. My feeling is that working with such patches is unlikely to be much of a burden since git has such good facilities (format-patch and am) for generating and using such patches. Emailing patches is tedious and error prone. Yes, git has good facilities for this, but it has even better facilities for sharing changes: pushing to public repos. Asking developers to refrain from pushing their experimental branches to public repos is somewhat hobbling, IMHO. Of course, if after we have gained some substantial experience with the patch method for the special case of sharing experimental development, we find that method is inhibiting our experimental development, we should move to a merge workflow instead like suggested by Brad King. But for now, let's give a good trial (at least 6 months) to our current rebase workflow including its constraint (if the resources I read are not overstating the case) that developers should refrain from sharing their experimental branches via public repos because it leads to bad further choices that typically come back to haunt you with a rebase workflow. I am not familiar with Brad King's merge workflow, but I think allowing some merge commits can be a good thing. A compromise between a rebase-only workflow and an unconstrained merge workflow would be to allow merge commits on master but only if the first parent of such merge commits is also on the master branch. Developers would still be allowed (encouraged?) to follow a rebase-as-much-as-possible workflow, but they could also push their experimental branches to public repos without having to worry about rebasing them later. This would allow for a concise summary of changes on master by running git log --oneline --first-parent master. Each non-merge commit on master would be shown along with the merge commit from each (non-rebased) topic branch, but the topic branch commits themselves would not be shown (because we passed --first-parent). Personally, I find merge commits to be a helpful way of partitioning the history of a project, especially when using gitk or git log --graph. They are kind of analogous to subdirectories in that not having merge commits is kind of like keeping all your files in one directory. When running git log --graph, merge commits make it easy to see which commits go together because they are shown on the same topic/experimental branch. Without merge commits, everything is just one lone thread of development. Of course it is possible to overuse merge commits, but generally if a topic branch is significant enough to share before rebasing it to master, then it's probably significant enough to warrant a merge commit on master when the time comes to bring the topic branch back into the fold. Hope this helps, Dave -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] More discussion of our adopted rebase workflow
Hi, Alan, On Sep 23, 2014, at 12:35 PM, Alan W. Irwin wrote: On 2014-09-23 09:54-0700 David MacMahon wrote: Emailing patches is tedious and error prone. I disagree. I have been applying user-generated patches to PLplot for years without any patch-related errors. And I really like the git format-patch command to generate a patch (which I have used to submit fixes to the cmake developer's list just like many others do there because that is the patch format particularly encouraged by Brad King for use by external developers). And I have had no problem already applying (using git am) an external patch for PLplot a git format-patch to PLplot supplied by an external developer. And sharing work using patches generated by git format-patch has not been an issue for years on the cmake-devel mailing list, the wine-devel list, and for the X intel graphics list and the cairo list when I was monitoring those. OK, maybe I my tolerance for handling patches is lower than others'. Git certainly does make it easy to generate and apply patches. It's almost the same a low-tech push/pull. Applying patches to the same commit from which they were generated will create a sequence of commits that have the same tree contents, log messages, and author info, but this sequence of commits will have different committer info and therefore they will be different commits (i.e. have different commit IDs). There are two issues here: 1) correctly applied patches will create different commits than the originals and 2) the patch files contain only the before/after SHA1 IDs of the patched files but no information about the un-patched files, which means that it is possible to successfully apply the patches to the incorrect commit. Issue 1 results in collaborators having different commit IDs for what are otherwise the same commit which can lead to confusion. Issue 2 results in collaborators having to carefully s pecify which commits their patches are based on (or more broadly applicable to) yet because of issue 1 they can't use commit IDs to do that. Yuck! In practice, this is rarely a problem for occasional/casual contributors, but for two actively collaborating developers sending patches back and forth it can be. Hope this helps Yes it does because workflow choice is an extremely important topic to discuss for any group developing software using git. I think we are mostly in agreement here. I'm happy to offer my thoughts where they are appreciated. I agree that we are mostly in agreement! :-) note that there is no simple way to enforce the first-parent workflow on the client side. Push hooks can provide server-side enforcements, but I don't think git provides any way to enforce client-side workflows. In contrast, that can easily be done for the current rebase workflow (see our README.developers file for details) so that our developers have the opportunity to catch rebase workflow errors right away rather than having to wait to see whether the server rejects their push. Just to nit pick: isn't this more of a pre-push check rather than client side enforcement? Nit picking aside, I agree that with rebase-only it easier to check for potential push problems on the client side *before* pushing. It sounds like you are on a prudent path forward! Dave -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] README suggestion
Hi, Alan, On Aug 28, 2014, at 10:46 AM, Alan W. Irwin wrote: On 2014-08-28 12:44-0400 Hazen Babcock wrote: In the README file, should I be able to click on the links when viewed here? http://sourceforge.net/p/plplot/plplot/ci/master/tree/ I don't think that is possible with plain text (which we want this file to be for the case when this README file is included, say, in a tarball). FWIW, Markdown is a very nearly plain text file format that is often used for README files (e.g. on github). I see in the link you provided that sourceforge supports Markdown, but only for README files with a markdown-like extension. If you would like the URLs in the README files to be links on the sourceforge repository browsing page (an possibly other places?), then it sounds like you could rename them to README.md (and README.developers.md etc). This might necessitate some reformatting if some previous plain text formatting gets mis-interpreted as unwanted markdown formatting. The Markdown syntax is very non-intrusive to a human reader. To humans, markdown files read very much like well formatted plain text files so they are well suited for inclusion in tarballs. Dave -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] README suggestion
Hi, Alan, On Aug 28, 2014, at 12:35 PM, Alan W. Irwin wrote: According to http://sourceforge.net/p/forge/documentation/Files-Readme/ it may be that all I would have to do was change the README name to README.md to make the SF software translate that file from markdown to html, but then according to that same documention we would not be in a good situation because any other file in the same directory with readme or README somewhere in the name would take precedence if updated later than README.md. Yeah, that multiple README resolution is potentially an issue. Wouldn't that be an issue even for plain text README files? Suppose someone changes README.emacs. Would README.emacs be the README file that gets shown when browsing the repository? Maybe they give priority to README (bare and with known extensions) over *[Rr][Ee][Aa][Dd][Mm][Ee]* to avoid this very problem? Dave -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Add doxygen comments to plot3d.c plfplot3dcl()
This is the first pass at adding some doxygen commentary to the new(-ish) functions that support arbitrary storage of 2-D data. Please let me know if this is on the right track. I think most of the related functions will have similarly worded explanations, so perhaps it would be better to document the concept in one place and then refer to it from each of the relevant functions. More commentary can be seen in the commit log of r10864. Any feedback would be most appreciated! Thanks, Dave --- src/plot3d.c | 41 + 1 files changed, 41 insertions(+), 0 deletions(-) diff --git a/src/plot3d.c b/src/plot3d.c index 653bb25..eecb129 100644 --- a/src/plot3d.c +++ b/src/plot3d.c @@ -923,6 +923,47 @@ c_plot3dcl( PLFLT *x, PLFLT *y, PLFLT **z, opt, clevel, nlevel, ixstart, ixn, indexymin, indexymax ); } +//-- +//! Plots a 3-d representation of the virutal function z, which is represented +//! by zops and zp. +//! +//! @param x The x values are stored as x[0..nx-1] +//! @param y The y values are stored as y[0..ny-1] +//! @param zops Pointer to a plf2ops_t structure of function pointers (see +//! plf2opts_t in plplot.h) which define how to perform various manipulations +//! (including retrieval) on the elements of the the 2D data field pointed to +//! by zp. Pointers suitable for passing as zops can be obtained for some +//! predefined types of 2-d data storage by calling one of the plf2ops_*() +//! functions (see plf2ops.c) or you can create your own set for arbitrary 2-d +//! storage formats. +//! @param zp Pointer to 2D data field. This pointer is passed to the +//! functions of zops whenever the 2D field needs to be maipulated. The +//! combination of zops and zp provides total flexibility in how the underlying +//! data values are managed. +//! @param nx The number of values in x. +//! @param ny The number of values in y. +//! @param opt Specifies options for the plot. It can be a bitwise OR-ing of +//! these: +//! - DRAW_LINEX : Draw lines parallel to x-axis +//! - DRAW_LINEY : Draw lines parallel to y-axis +//! - DRAW_LINEXY: Draw lines parallel to both axes +//! - MAG_COLOR:Magnitude coloring of wire frame +//! - BASE_CONT:Draw contour at bottom xy plane +//! - TOP_CONT: Draw contour at top xy plane (not yet) +//! - DRAW_SIDES: Draw sides around the plot +//! - MESH: Draw the under side of the plot +//! or any bitwise OR'd combination, e.g. MAG_COLOR | DRAW_LINEX +//! @param clevel z values at which to draw contours +//! @param nlevel Number of values in clevels +//! @param ixstart Index of first x coordinate to include in plot +//! @param ixn Number of x coordinates to inlcude in plot +//! @param indexymin Array which specifies the min y index for each x +//! index in range ixstart, ixn. +//! @param indexymax Array which specifies the max y index for each x +//! coordinate (following the convention that the upper range limit is one more +//! than actual index limit) for an x index range of ixstart, ixn. +//-- + void plfplot3dcl( PLFLT *x, PLFLT *y, PLF2OPS zops, PLPointer zp, PLINT nx, PLINT ny, PLINT opt, -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Coloring 3D plots
I'd like to be able to make plsurf3d or plplot3d plots of complex data where the Z axis is the magnitude and the color is the phase of the complex values. Currently, these methods only offer a MAG_COLOR option. I think this colors the plots based on the real (i.e. signed) value rather than the absolute value. That semantical distinction aside, the point is that the 3D plots can only be colored, if at all, based on the z axis displacement of the surface (or line) plot rather than some other attribute of the 2D data field being plotted. I think this would be best implemented by creating enhanced versions of these functions that accept an additional 2D data field whose values would be used to determine colors. Here is the current declaration of plfplot3dcl... void plfplot3dcl( PLFLT *x, PLFLT *y, PLF2OPS zops, PLPointer zp, PLINT nx, PLINT ny, PLINT opt, PLFLT *clevel, PLINT nlevel, PLINT ixstart, PLINT ixn, PLINT *indexymin, PLINT *indexymax ); The enhanced, arbitrary color version would be this... void plfplot3dcl2( PLFLT *x, PLFLT *y, PLF2OPS zops, PLPointer zp, PLF2OPS cops, PLPointer cp, // NEW PARAMETERS PLINT nx, PLINT ny, PLINT opt, PLFLT *clevel, PLINT nlevel, PLINT ixstart, PLINT ixn, PLINT *indexymin, PLINT *indexymax ); ...where the two new parameters, cops and cp, would represent the 2D data field to be used to determine colors. cops==NULL would be the same as not specifying MAG_COLOR, and the MAG_COLOR flag of opt would be ignored. Using this approach to make the 3D plots of complex data described above, I would pass the pointer to the 2D complex data for both zp and cp. zops would point to a plf2ops structure whose get function returns the magnitude of the desired point and cops would point to a plf2ops structure whose get function returns the phase of the desired point. I'd like to get some feedback/encouragement/lack-of-discouragement before I embark on this change, so if you have any of the above please let me know. Thanks, Dave -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Add some comments about the plfplot3dcl function
This is the first pass at adding some commentary to the new(-ish) functions that support arbitrary storage of 2-D data. Please let me know if this is on the right track. I think most of the related functions will have similarly worded explanations, so perhaps it would be better to document the concept in one place and then refer to it from each of the relevant functions. More commentary can be seen in the commit log of r10864. Any feedback would be most appreciated! Thanks, Dave --- src/plot3d.c | 34 ++ 1 files changed, 34 insertions(+), 0 deletions(-) diff --git a/src/plot3d.c b/src/plot3d.c index 653bb25..b4b065a 100644 --- a/src/plot3d.c +++ b/src/plot3d.c @@ -923,6 +923,40 @@ c_plot3dcl( PLFLT *x, PLFLT *y, PLFLT **z, opt, clevel, nlevel, ixstart, ixn, indexymin, indexymax ); } +//-- +// void plfplot3dcl(x, y, zops, zptr, nx, ny, opt, clevel, nlevel, +// ixstart, ixn, indexymin, indexymax) +// +// Plots a 3-d representation of the virutal function z, which is represented +// by zops and zp. The x values are stored as x[0..nx-1]; the y values as +// y[0..ny-1]. The values of the virtual z function are obtained by passing x +// and y indices and zp to one of the functions in zops. zops is a pointer to +// a structure of function pointers (see plf2opts_t in plplot.h) which define +// how to perform various operations (including retrieval) on the elements of +// The ability to provide opaque data via zp and a set of operator +// functions via zops provides total flexibility in how the underlying data +// values are managed. Pointers suitable for passing as zops can be obtained +// for some predefined types of 2-d data storage by calling one of the +// plf2ops_*() functions (see plplot.h) or you can create your own set for +// arbitrary 2-d storage formats. +// +// The integer opt specifies: +// +// DRAW_LINEX : Draw lines parallel to x-axis +// DRAW_LINEY : Draw lines parallel to y-axis +// DRAW_LINEXY: Draw lines parallel to both axes +// MAG_COLOR:Magnitude coloring of wire frame +// BASE_CONT:Draw contour at bottom xy plane +// TOP_CONT: Draw contour at top xy plane (not yet) +// DRAW_SIDES: Draw sides around the plot +// MESH: Draw the under side of the plot +// +// or any bitwise combination, e.g. MAG_COLOR | DRAW_LINEX +// indexymin and indexymax are arrays which specify the y index limits +// (following the convention that the upper range limit is one more than +// actual index limit) for an x index range of ixstart, ixn. +//-- + void plfplot3dcl( PLFLT *x, PLFLT *y, PLF2OPS zops, PLPointer zp, PLINT nx, PLINT ny, PLINT opt, -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Broken drivers/tkwin.c?
Thanks, Argen! I also noticed this when compiling tkwin.c... drivers/tkwin.c:398: warning: assignment makes pointer from integer without a cast This is because XOpenDisplay is not declared in any #included files. I think because I'm on Mac OS X and Tk is not based on X11 on that platform. I see a lot of #ifdef MAC_TCL in the source code, but I can't find that being #defined (or #undefed) anywhere nor any cmake files that refer to the MAC_TCL macro. Thanks again, Dave P.S. Here's the full command line that make used and the resulting output... cd /Users/davidm/local/src/plplot/tmp/drivers /opt/local/bin/gcc -Dtkwin_EXPORTS -DHAVE_CONFIG_H -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fPIC -I/Users/davidm/local/src/plplot/include -I/Users/davidm/local/src/plplot/lib/qsastime -I/Users/davidm/local/src/plplot/lib/nistcd -I/Users/davidm/local/src/plplot/tmp -I/Users/davidm/local/src/plplot/tmp/include -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -I/usr/include -I/Users/davidm/local/src/plplot/bindings/tcl -I/Users/davidm/local/src/plplot/tmp/bindings/tcl -I/Users/davidm/local/src/plplot/bindings/tk-x-plat -I/Users/davidm/local/src/plplot/bindings/tk -DUSINGDLL -o CMakeFiles/tkwin.dir/tkwin.c.o -c /Users/davidm/local/src/plplot/drivers/tkwin.c /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'plD_open_tkwin': /Users/davidm/local/src/plplot/drivers/tkwin.c:398: warning: assignment makes pointer from integer without a cast /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'Init': /Users/davidm/local/src/plplot/drivers/tkwin.c:946: warning: assignment makes pointer from integer without a cast /Users/davidm/local/src/plplot/drivers/tkwin.c:959: warning: assignment makes pointer from integer without a cast /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'CreatePixmap': /Users/davidm/local/src/plplot/drivers/tkwin.c:1235: warning: assignment makes pointer from integer without a cast -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot + Windows + Octave
Hi, Alan, On Jan 3, 2011, at 12:33 AM, Alan W. Irwin wrote: Could you take a look at what I have done with swig? In particular, I felt my copying of some of the wrappers (especially the laborious transformation of matrix results) used in matwrap was not really taking full advantage of swig capabilities. I'm no expert on Octave internals, but I assume they have a certain structure for representing matrices, so maybe it would be worthwhile to create a set of plf2ops functions to allow use of their matrix format without any copying/rearranging of data. Just an idea, Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Building on Mac OS X 10.6 (aka Snow Leopard)
I'm slowly getting back to some plplot development. Since my last involvement with plplot, I have received a new computer with Mac OS X 10.6.5 (aka Snow Leopard) and a 64 bit processor (Intel Core i5). I noticed a few issues when building plplot on this new system. I'm documenting them all here for posterity, though I have a few questions mixed in. Apologies in advance for the lengthiness. = freetype I think freetype is only for older plplot devices like the gd driver, but I'm not sure. Please correct me if I'm wrong, but as I recall, freetype is not used by the xwin driver, which I think is Hershey fonts only. In any event, I installed freetype using MacPorts so it lives under /opt/local rather than /usr/local so the FindFreetype.cmake module didn't find it. If this ends up being an issue, it is easy to solve through cmake command line options or adding suitable paths to FindFreetype.cmake. = wxwidgets Snow Leopard includes wxwidgets 2.8, which links to Apple's 32-bit-only Carbon framework rather than the 64-bit-capable Cocoa framework. Therefore anything, such as plplot, that links to the wxwidgets libraries on Snow Leopard must also be 32 bit. So apparently one must choose between 64-bit plplot without wxwidgets or 32-bit plplot with wxwidgets. wxwidgets 2.9 on Mac OS X links to the Cocoa framework so that would work with 64-bit plplot (assuming that plplot is compatible with wxwidgets 2.9). I found this out fairly late in the build when the link failed. I think the cmake tests could be updated to detect the architecture difference and disable the wxwidgets stuff if it is found to be incompatible. I chose to build plplot using the i386 architecture rather than the x86_64 architecture by running... cmake -DCMAKE_OSX_ARCHITECTURES:STRING=i386 .. This enabled the -arch i386 compiler flag, which means that I have to use one of Apple's gcc versions since the gcc versions I installed via MacPorts seem to croak on this option. This has the side effect of eliminating Fortran since (AFAIK) Apple doesn't provide a Fortran compiler. Maybe I could use Apple's gcc and MacPorts gfortran, but I don't really need Fortran support, so I've not investigated that hybrid configuration. = qhull In the output of the above cmake command, I noticed that HAVE_QHULL is now OFF. This is because I had installed it via MacPorts as a non-universal binary so it had only x86_64 support in it. I reinstalled it as a universal binary. = octave I installed Octave 3.2.4 via MacPorts. The MacPorts octave portfile does not build or provide a way to build a universal binary, so my octave in x86_64 only so I can't use it and wxwidgets. = pthread Does anyone know if the comments in cmake/modules/xwin.cmake about pthread on Mac OS X 10.4 and 10.5 are still relevant for 10.6? I'd be happy to try this out if someone can let me know what to look for in terms of working vs not working. = agg HAVE_AGG is blank (i.e. neither ON nor OFF) even though I have it installed. It seems like this is only used by wxwidgets with freetype, but since I don't have freetype enabled (see above) it makes sense that this would be blank. It does get me wondering more about the wxwindows and freetype stuff. What is the status of the wxwidgets driver and bindings? They defaulted to ON which leads on to think they are not deprecated. If I eliminate the wxwidgets stuff I think I would be able to switch back to an x86_64 build, but I kind of like the concept of plplot inside a wxwidgets application. = cairo I also discovered that I needed to re-install cairo as a universal binary. Again, this happened part way through the build. Does cmake not try to link against libraries that it finds or does it not use the same flags (e.g. -arch i386) used to build plplot? It seems like cmake should have been able to tell me that my x86_64 cairo installation was not usable with the CMAKE_OSX_ARCHITECTURE setting I used, but I only found out part way through the build. = aquaterm I was unable to build the aquaterm driver. The output of cmake included -- Found AQT: /opt/local/include/AquaTerm/AQTAdapter.h, but when I run make VERBOSE=1 I get... cd /Users/davidm/local/src/plplot/tmp/drivers /opt/local/bin/gcc -Daqt_EXPORTS -DHAVE_CONFIG_H -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fPIC -I/Users/davidm/local/src/plplot/include -I/Users/davidm/local/src/plplot/lib/qsastime -I/Users/davidm/local/src/plplot/lib/nistcd -I/Users/davidm/local/src/plplot/tmp -I/Users/davidm/local/src/plplot/tmp/include -ObjC -DUSINGDLL -o CMakeFiles/aqt.dir/aqt.c.o -c /Users/davidm/local/src/plplot/drivers/aqt.c /Users/davidm/local/src/plplot/drivers/aqt.c:33:32: error: AquaTerm/AQTAdapter.h: No such file or directory Why is there no -I/opt/local/include on the gcc command line given that cmake found the required header file /opt/local/include/AquaTerm/AQTAdapter.h? FWIW, the directory is
[Plplot-devel] Broken drivers/tkwin.c?
I think drivers/tkwin.c got broken in r11405. I get this error when trying to compile it... drivers/tkwin.c: In function 'FillPolygonCmd': drivers/tkwin.c:859: error: 'npts' undeclared (first use in this function) Not sure how to fix it, but maybe change npts to pls-dev_npts? Thanks for any ideas, Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
On Dec 22, 2010, at 9:05 PM, Maurice LeBrun wrote: A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there are heap-vs-stack performance implications -- e.g. directly moving from a fixed allocation to a malloc/free each time plfill() is called could suck for the many small-n-vertices polygon case. Using per-stream polyline buffers is better but more convoluted. The short term solution is definitely just recompile with a higher limit. How about alternate versions of these functions that allow the caller to provide (via a pointer) the workspace buffer? That would place the onus of malloc/free on the caller, but would also allow the caller to decide how to handle memory allocation failures as well as reuse the same workspace buffer for multiple calls. We could even provide a plpoly_alloc function that would take convenient parameters (e.g. npts) from the caller, compute the buffer size required, allocate a buffer of that size, and return the resulting pointer (or NULL if the allocation failed). The existing implementations of plfill et al. could simply call the new alternate versions passing in pointers to their statically allocated buffers. Just an idea, Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fix for 79-character truncation on plgfnam
Hi, Alan, On Dec 18, 2010, at 10:57 AM, Alan W. Irwin wrote: Another model for plgnver, plgndev, and plgnfnam is one similar to strlcpy that is discussed by Todd C. Miller and Theo de Raadt at http://www.gratisoft.us/todd/papers/strlcpy.html. That is a most interesting paper to read. I am not necessarily advocating something similar to this model API. I leave that to those more knowledgable in C than I am. However, I am mentioning this paper for further discussion. It seems like strlcpy is a more convenient alternative to strncpy, but I don't see how this would solve the allocation problem. Wouldn't the user still need to ensure that a large enough buffer has been allocated? If so, the problem of determining how large is large enough still remains. Am I missing something? aside to Dave Can you remember the name of the function you were using as the model for your API suggestion for plgnver, plgndev, and plgnfnam? If so, that will give us a chance to dig into the official documention of that function like we can currently do for getcwd and strlcpy. /aside to Dave OK, digging way back into my mental archives (and googling), I think I first came across this approach in a previous life when I did Windows programming. An example of this approach can be seen in the Windows GetShortPathName function (and probably others as well)... http://msdn.microsoft.com/en-us/library/aa364989(v=vs.85).aspx I mis-remembered the exact details of the return code. The WIN32 functions seem to return the total size needed iff the buffer pointer is NULL and the size is given as 0. This shouldn't really change the fundamentals of what I wrote earlier, however. On 2010-12-18 13:59- Andrew Ross wrote: Down side for us [of automatic allocation] is that allocated memory in C may be difficult to use in other languages. I think automatic allocation by the library function, while not a big drawback, has a few potential points against it. One it that memory allocation is one of the (potentially) more expensive operations, so minimizing it is desirable. I don't think the use cases in question will result in this being a significant factor. The other issue is that once the library has allocated and populated the buffer, language bindings sometimes (typically?) require that the contents be copied into a suitably sized buffer that the scripting language manages. In this case the result is a double allocation (one by the library function, one by the scripting language), a extra strcpy from library buffer to scripting language buffer, and a free of the buffer returned by the library function. Getting the size first, allocating a buffer using he scripting language memory management routines, then passing the pointer to the library routine is, IMHO, more cleanly amenable to scripting language bindings (though I write mine manually so I don't know whether this would apply to SWIG generated bindings). Again, I don't think these factors will be significant for the functions under discussion, so I'll be happy with whatever consensus emerges. Dave -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fix for 79-character truncation on plgfnam
On Dec 18, 2010, at 6:30 PM, Alan W. Irwin wrote: On 2010-12-18 11:34-0800 David MacMahon wrote: Am I missing something? See their example 1d where they check for truncation. Instead of taking an error return at that point as they did in their sample code the user could instead realloc if they liked as in your original suggestion. Thanks, I did miss something! :-) The strlcpy model seems very similar to the WIN32 convention, only better in that it is more rigorously documented vis-a-vis NUL termination. Just because it appears to be better documented on the null-termination guarantee issue, I suggest we adopt the strlcpy model. This gives the user in any language freedom to do anything they like if the returned size (which never counts the null terminator) is = the value of n in the call. I agree! For high-level languages like Python where the uses don't have to worry about allocation, they could just call the function again with n chosen to be the previous returned value + 1. For high level languages like Python, any (re-)allocation could happen in the bindings and therefore be hidden from the end user. Also, I don't think we should use the wrinkle present in GetShortPathName of doing something special for the NULL buffer, size=0 call. That does add a bit of convenience (but is not a necessity) for languages such as C where the buffer is alloced beforehand, I agree about not treating a NULL pointer as a special case, but strlcpy inherently treats size=0 as a special case (i.e. no NUL terminator). When size=0, strlcpy ignores the pointer and gives the same result as the WIN32 convention (though the WIN32 convention requires the pointer to be NULL). but that wrinkle makes no sense for higher level languages such as Python where the correctly sized buffer is created as needed. For example, a typical Python call to plgfnam is fnam = plgfnam() With plgnfnam that would be changed to something like (needed_size, fnam) = plgnfnam(100) if needed_size = 100: # Oops, 100 was too small. fname = plgnfnam(needed_size+1)[1] This is an example of why I like to hand code language bindings. IMHO, the plgnfnam function, if it is even exposed in the scripting language, should take no arguments and always return a string containing the entire contents. Why make the user provide an initial guess? This requires them to check whether their guess was big enough and try again (without forgetting the +1) if it wasn't. How inconvenient! Why not just do all of that for them inside the bindings for the high-level language's plgfnam call (which would call plgnfnam under the covers)? Dave -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fix for 79-character truncation on plgfnam
Hi, Alan,
On Dec 16, 2010, at 6:54 PM, Alan W. Irwin wrote:
Here is what I propose instead of this temporary measure. We go with
a backward-incompatible API change (and associated soname bump to
force everybody to recompile) of
c_plgfnam( char *fnam ); == c_plgfnam( char *fnam, PLINT n);
where n is the size of the buffer that has been allocated.
Internally, c_plgfnam will use n for the strncpy call as well as
figuring out the last byte to zero.
Note, the other two PLplot functions (plgver and plgdev) that return
character strings have recommendations in the documentation to
allocate 80-byte buffers to contain the version string and device
name.
I notice that all of these functions currently have a null return type. One
approach I've seen elsewhere, is to have functions like this return an int
indicating how many bytes were copied into the buffer if the pointer given is
non-null *or*, if the given pointer is null, how many more bytes are needed to
fill the buffer.
This allows the client code to determine the buffer size needed, (re-)allocate
the buffer dynamically, then fill the buffer...
bufsize = plgver(NULL, 0);
buf = (char *)malloc(bufsize+1);
plgver(buf, bufsize);
buf[bufsize] = '\0';
// Note how this can be used to determine
// whether a buffer is already big enough
extra = plgfnam(NULL, bufsize);
if(extra 0) {
buf = (char *)realloc(buf, bufsize+extra+1);
}
bufsize += extra;
// if extra 0, bufsize will be smaller
// than size of region allocated
plgfnam(buf, bufsize);
buf[bufsize] = '\0';
Just an idea,
Dave
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Legends
Hi, Bill, On Oct 6, 2010, at 8:19 , Schwab,Wilhelm K wrote: a performance argument is a stretch I agree, that's why I prefaced my comments with... For the smallish amounts of legend text it probably doesn't matter that much either way Since plotting is inherently much more number-heavy than text-heavy, this may never be an issue for plplot. On the other hand, if it ever did arise, it would be nice to have a single unified approach for passing an array of strings instead of two different ways. Another argument for keeping it char ** would be inertia. It's already written this way (designer's choice) so don't change it unless there is a compelling reason. Dave -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Legends
On Oct 5, 2010, at 21:42 , Alan W. Irwin wrote: On 2010-10-05 22:19-0400 Schwab,Wilhelm K wrote: I was interested in building it (5.9.7) to try the legend code. Is there a reason for the double pointer? It seems that this part\0that part\0...\0and the last part\0\0 would do the job just as easily?? I am willing to keep an open mind about changing the present approach if we run into trouble interfacing const char ** text to other languages. FWIW, I vote for keeping it as char**. For the smallish amounts of legend text it probably doesn't matter that much either way, but with more and/or larger strings that might come from different locations, the cost of copying into one buffer can become significant. Creating an array of char* and populating with pointers into a long buffer containing back-to-back strings is not nearly so onerous (presuming you know how many strings you have to begin with so you can allocate a big enough char* array). Does the library strdup the passed in strings, render them before returning, or just copy the pointers for later rendering? Thanks, Dave (who has obviously not examined the legend implementation!) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Propagation of C example changes to our other language examples is needed
On May 6, 2010, at 7:27 , Arjen Markus wrote: this is indeed very puzzling! I have never seen it before - and all the stuff I used I have used countless times before. Also puzzling: why does a repeated invocation of test-drv-info via make examine different drivers? It must be recording some information. Have you tried from a clean build tree? Sometimes after making Makefile changes, old build products from previous builds can cause weird problems because make no longer considers them but the tools make invokes might consider/use them. Just an idea, Dave -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] proposal for consideration: plcont_phase.c for contour plots of phase data
Hi, Maurice and Alan, On Apr 20, 2010, at 0:39 , Maurice LeBrun wrote: The general remapping of coordinates is a crucial part of it. I think you are referring to the 0/2pi coordinate seam when transforming a rectilinear grid to a polar grid. I think Ed (correct me if I'm wrong, Ed) is referring to a different problem of contouring the phase (i.e. angle or arg) of complex data values regardless of the grid type (i.e. rectilinear or polar). One approach I've taken in the past when visualizing 2d complex data fields (and would like to add to plsurf3d et al) is to make a surface plot with z values based on the amplitudes and color values based on the phase. Using the phase as the hue component of HSL (or HSV) makes for a nice colorization that handles phase wrapping intrinsically since the HSL color wheel wraps smoothly itself. Unfortunately, this trick doesn't help for contouring data. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] proposal for consideration: plcont_phase.c for contour plots of phase data
Hi, Ed, On Apr 19, 2010, at 13:47 , Ed Zaron wrote: it involves wrapping the phases locally for the corners of each grid cell. In addition to the already mentioned possibility of creating a wrapped phase copy of your data array, another alternative you might want to consider is using the plfcont routine rather than c_plcont (aka plcont). The plf variants of 2d data functions are passed data via a pointer to the data and a pointer to either an evaluator function or (for new style plf functions) a structure of pointers to a set of operator functions. For each point, the 2d data function will access the user data via the evaluator function (which is passed the user data pointer). If you could create an evaluator function that performed the local phase wrap for each point on-the-fly, I think you'd be able to do what you want with the existing plplot API without having to create a wrapped phase (or even unwrapped phase) copy of your data. My guess is that whatever you added to plcont's internals could be refactored into a suitable evaluator function. If you look at the implementation of c_plcont, you'll see that it simply calls plfcont with a particular choice for f2eval and f2eval_data. In your case, f2eval_data would be a pointer to your data and f2eval would be replaced with your local phase wrap evaluator function. Hope this helps, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Incompatible architectures in building on OS X with 64-bit Ada compiler
Hi, Jerry, On Apr 16, 2010, at 3:16 , Jerry wrote: * Two PLplot-built libraries are 32-bit and ONE OF THESE IS FIRST IN THE FILE LIST. The very first file in the file list is reported as 32-bit: Non-fat file: ./qt.cpp.o is architecture: i386 How did this file managed to get built as 32-bit only? Is it maybe left over from an old build? I suggest you delete this library and rebuild it with make VERBOSE=1 to capture the commands used to build it. That will probably provide some more clues. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Incompatible architectures in building on OS X with 64-bit Ada compiler
On Apr 16, 2010, at 15:56 , Jerry wrote: /usr/bin/c++ -bundle -headerpad_max_install_names -o qt.so CMakeFiles/qt.dir/qt.cpp.o CMakeFiles/qt.dir/__/bindings/qt_gui/ plqt.cpp.o ../src/libplplotd.9.7.0.dylib /usr/lib/libm.dylib - framework QtSvg -framework QtGui -framework Carbon -framework AppKit -framework QtXml -framework QtCore /usr/lib/libz.dylib - framework ApplicationServices /usr/lib/libltdl.dylib /usr/lib/ libdl.dylib ../lib/csa/libcsirocsa.0.0.1.dylib ../lib/qsastime/ libqsastime.0.0.1.dylib /usr/lib/libm.dylib Maybe the -framework Carbon is confusing things? I thought you were using the Cocoa version of Qt, so where does that come from? Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Commit of universal coordinate transform support - request for testing
On Apr 12, 2010, at 9:33 , Hezekiah M. Carty wrote: The global transform is applied after the pltr-type transforms, While the signatures are the same, I'm not sure that pltr[0-2] could be used with plstransform in a simple manner. The intent of the function is closer to that of the mapform parameter in plmap and plmeridians where the transform is from unprojected world coordinates - projected world coordinates. If I recall correctly, the pltr* functions transform data-grid coordinates ((0, 0) to (nx -1, ny - 1)) to world coordinates so they may not work with plstransform exactly as they are, at least not in all cases. They do, however, still play an important role. Thanks for that clarification. This leads to my next question! :-) Are the world coordinates given to plenv etc the projected (i.e. transformed) world coordinates? If one has setup a transformation like the example you included in you original message, would a plline call to plot a line between points of equal latitude but different longitudes still draw a straight line while a plpath call to do the same would draw an arc according to the established transformation? Maybe this will all be obvious once I actually read the docs and look at the example code! Thanks again, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Commit of universal coordinate transform support - request for testing
On Apr 12, 2010, at 12:16 , Alan W. Irwin wrote: I think it is time that we take advantage of that free map data rather than limiting ourselves to just the four map data files that are currently accessible from PLplot. Ideally the availability of free GIS data (along with changes to plmap to allow access to those data) should allow us to replace example 19 to provide examples of some really high-quality maps that are built directly from free GIS data by PLplot. I think this is a great idea! My only caution would be to watch out for including too much GIS-specific functionality within PLplot. IMHO, it would be preferable to use external (and externally maintained!) libraries if/when possible. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plpoin codes 92 and 95
Thanks, Alan, On Apr 7, 2010, at 13:55 , Alan W. Irwin wrote: I also plan to change the index for underscore to point to a unique Hershey index that currently has no associated glyph. FWIW, I think PGPLOT maps the underscore to Hershey symbol 590. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plpoin codes 92 and 95
On Apr 7, 2010, at 15:19 , Alan W. Irwin wrote: On 2010-04-07 14:27-0700 David MacMahon wrote: FWIW, I think PGPLOT maps the underscore to Hershey symbol 590. I confirmed that information with http://www.astro.caltech.edu/~tjp/pgplot/figb2.html That index position is empty with PLplot so that is the index position I will adopt for underscore with PLplot as well. I don't know much about the Hershey fonts, but I thought that the codes were predefined so that 590 would always be the same Hershey symbol. Is that not true? IOW, are the PGPLOT (or PLplot) Hershey codes specific to PGPLOT (or PLplot) rather than to Hershey fonts in general? Here's what I think PGPLOT uses for the underscore's coordinates... Bounding box... miny, baseliney, maxy, minx, maxx = [-16, -9, 12, -9, 10] Stroke (in same coordinate frame as bounding box)... x1, y1, x2, y2 = [-9, -11, 9, -11] Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plpoin codes 92 and 95
Example 6 on the PLplot website shows centered dots for codes 92 and
95 rather than the expected backslash ('\') and underscore ('_').
Code 94 shows as a degree symbol rather than a circumflex ('^'), but
at least that matches PGPLOT (see http://www.astro.caltech.edu/~tjp/
pgplot/hershey.html).
FWIW, the docs for plpoin say If code is between 32 and 127, the
symbol is simply the corresponding printable ASCII character in the
default font.
I think this could be fixed in the Hershey font mappings, but I
haven't yet tried to do so since I think it might be trivial for
others on the list to fix this or maybe it's even the intended behavior.
Dave
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plpoin codes 92 and 95
On Apr 5, 2010, at 17:09 , Alan W. Irwin wrote: I will commit when done and the result should look good for our TTF devices (e.g., all our cairo and qt devices) and our PostScript devices. After that commit, the Hershey font error will remain for our devices that still use Hershey fonts. I don't care since I don't use such devices any more for critical work. If you do care, I will be happy to accept your patch. Thanks, Alan. Because this also affects the text in labels in the xwin driver, I think I would miss the underscore enough to try to fix at least that glyph. Our Hershey fonts can be regenerated from the code in the fonts subdirectory if you specify the -DBUILD_HERSHEY_FONTS=ON option. However, you would have to figure out the format contained in the various *.c files and fix the drawing data corresponding to codes 92, 94, and 95. Since PGPLOT uses Hershey fonts and has correct glyphs for 92 and 95, it shouldn't be too hard (famous last words! :-)) to fix those. Code 94 could be trickier. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -bg with alpha gives strange overlay effect on x02c
Hi, Hez, On Mar 18, 2010, at 21:16 , Hezekiah M. Carty wrote: The checkerboard background seems to be a semi-standard approach for viewing transparent images (Gimp uses something similar). I'm not sure it is a good idea for our interactive devices though, as it makes it very difficult to see the details of a plot. I would prefer to keep the white background as the standard for non-transparent windows as it maintains better readability. I agree that a checkerboard (or even transparent) back-background makes it harder to see the details of a plot with a non-opaque background on interactive devices, but I think one use case for even requesting a non-opaque background on an interactive device in the first place is to preview how different alpha values would look on a non-interactive device. In this case, some type of patterned back- background (e.g. a checkerboard) would be more useful than a single color background, IMHO. If one is primarily interested in actually visualizing data on an interactive device (oh, what a concept! :-)), one would probably choose to use the default opaque background. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -bg with alpha gives strange overlay effect on x02c
On Mar 15, 2010, at 14:32 , Alan W. Irwin wrote: Then display -immutable test_transparent.png really does show the desktop underneath the plot which indeed is a really cool-looking effect. Using a very recent ImageMagick (6.6.0), display gives me the checkerboard background without the -immutable option and a black background with that option when looking at an image with a transparent background. This might be an X server limitation or window manager limitation, but it shows that this feature is not universally available. (Without that -immutable option, display replaces a transparent background with a checkerboard background which apparently is something of an industry standard to signal you really do have a transparent background.) I agree that this *can be* a really cool-looking effect, but IMHO it can also be a really annoying/confusing looking effect (depending on what's underneath/behind). I think it would be nice to provide the user the ability to choose how transparent backgrounds are rendered (i.e. either see-through to windows underneath/behind or use a predefined opaque background, e.g. checkerboard). Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -bg with alpha gives strange overlay effect on x02c
Hi, Alan, On Mar 15, 2010, at 17:49 , Alan W. Irwin wrote: On 2010-03-15 15:49-0700 David MacMahon wrote: Using a very recent ImageMagick (6.6.0), display gives me the checkerboard background without the -immutable option and a black background with that option when looking at an image with a transparent background. This might be an X server limitation or window manager limitation, but it shows that this feature is not universally available. Please be explicit about exactly what you did because our devices other than the three different svg ones are producing bad transparent background results that depend very much on details. Thanks for pressing me on this one. It looks like I found a quirk with the display program. I was using an image I had created with GIMP that I knew had a transparent background. This image happens to be rather large (in pixels). It seems that the window created by display -immutable foo.png will have a non-opaque background if foo.png is non-opaque and the window's size fits in the root X window (i.e. needs no panner). Because my test file was large in pixels, it showed up in the display window with a black background and a little panner window for navigating around. When I followed the steps you gave to create test_transparent.png, then display -immutable did indeed show it using a transparent window background (neat, except that I see my very cluttered desktop underneath! :-)). If I run display -immutable -resize 1440x900! test_transparent.png it still comes up with transparency (my root window is 1440x900 as shown by xwininfo -root). If I change either (or both) resize dimension to exceed the root window size, then I'm back to the solid black background. Therefore, I assume this is not an ImageMagick issue. See what happens when you assume! :-) I agree that this *can be* a really cool-looking effect, but IMHO it can also be a really annoying/confusing looking effect (depending on what's underneath/behind). I think it would be nice to provide the user the ability to choose how transparent backgrounds are rendered (i.e. either see-through to windows underneath/behind or use a predefined opaque background, e.g. checkerboard). This would not be a good idea for file devices. There, you want the user running the file viewing application (say with something like the display -immutable option) to control how transparent backgrounds are rendered. Yes, obviously(?) for file devices we want real transparency. In the separate case of interactive devices we should probably just follow what is done by the underlying external stack of libraries (such as the pango/cairo stack of libraries for -dev xcairo and the Qt4 stack of libraries for -dev qtwidget). I'm no expert on the PLplot devices, but my understanding is that the xcairo device is a cairo widget or surface drawn in a regular X window that has its own background. If that's the case, then perhaps we would need to create the window with either a transparent or checkerboard background before drawing in it with cairo? Of course, if that external stack of libraries does offer the option of rendering transparent backgrounds as checkerboard (which I believe from my reading is a de facto standard started by Adobe photoshop) or as actually transparent for interactive devices, then it makes sense to give PLplot users interactive control over that choice via a driver option. IMHO, the choice of transparent or non-transparent window backgrounds transcends the particular interactive device chosen. PLplot already has generic -nopixmap and -db options for X-based drivers. A similar PLplot option (i.e not a driver option) to choose between opaque and non-opaque *window* backgrounds seems appropriate (again, IMHO). Given that transparent window backgrounds are more resource intensive (does it even work without an accelerated graphics driver?), I think the default should be an opaque (of some sort) window background even when the plot background is non-opaque. Anyhow, our current list of devices that treat transparent background properly is limited to just svg, svgcairo, and svgqt as far as I can tell. I hope we can soon expand that list both to the xcairo and qtwidget interactive devices as well as many other file devices. I certainly agree that it would be good to expand the list of devices that treat transparent background properly. For file outputs, there seems to be little ambiguity, but defining proper treatment for interactive devices seems not so clear (pun partially intended! :-)). Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
On Mar 13, 2010, at 16:43 , Alan W. Irwin wrote: I have committed this patch (revision 10864). Thanks, Alan!!! Thanks, Dave, for all your work on this arbitrary storage of 2D data API. You're welcome. Thanks for including it! Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
Hi, Alan, On Mar 14, 2010, at 10:29 , Alan W. Irwin wrote: That is revision 10869 should be the same as David's tree that produced his patch I can confirm that r10869 contains all the changes from my patch. Thanks again, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
This is a roll-up of all previous PLplot patches related to supporting arbitrary storage of 2D user data. This patch is based on (and should apply cleanly to) svn/trunk r10859. Adds support for arbitrary storage of 2D user data. This is very similar to the technique employed by some existing functions (e.g. plfcont and plfshade) that use evaluator functions to access 2D user data that is stored in an arbtrary format. The new approach extends the concept of a user-supplied (or predefined) evaluator function to a group of user-supplied (or predefined) operator functions. The operator functions provide for various operations on the arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan, minmax, and f2eval. To facilitate the passing of an entire family of operator functions (via function pointers), a plf2ops_t structure is defined to contain a pointer to each type of operator function. Predefined operator functions are defined for several common 2D data storage techniques. Variables (of type plf2ops_t) containing function pointers for these operator functions are also defined. New variants of functions that accept 2D data are created. The new variants accept the 2D data as two parameters: a pointer to a plf2ops_t structure containing (pointers to) suitable operator functions and a PLPointer to the actual 2D data store. Existing functions that accept 2D data are modified to simply pass their parameters to the corresponding new variant of the function, along with a pointer to the suitable predefined plf2ops_t stucture of operator function pointers. The list of functions for which new variants are created is: c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc, c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and c_plgriddata. The new variants are named the same as their corresponding existing function except that the c_ prefix is changed to plf (e.g. the new variant of c_plmesh is called plfmesh). Adds plfvect declaration to plplot.h and changes the names (and only the names) of some plfvect arguments to make them slightly clearer. In order to maintain backwards API compatibility, this function and the other existing functions that use evaluator functions are NOT changed to use the new operator functions. Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d. Moves the definitions of pltr2f (already declared in plplot.h) from the sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c. Removes pltr0f declaration from plplot.h. Changes x08c.c to demonstrate use of new support for arbitrary storage of 2D data arrays. Shows how to do surface plots with the following four types of 2D data arrays: 1) PLFLT z[nx][ny]; 2) PLfGrid2 z; 3) PLFLT z[nx*ny]; /* row major order */ 4) PLFLT z[nx*ny]; /* column major order */ --- bindings/f77/sccont.c | 182 - bindings/f95/sccont.c | 182 - examples/c/x08c.c | 45 -- include/plplot.h | 238 ++-- src/CMakeLists.txt|1 + src/plcont.c | 207 +++- src/plf2ops.c | 426 +++ ++ src/plgridd.c | 120 -- src/plimage.c | 49 +-- src/plot3d.c | 212 - src/plshade.c | 81 -- src/plvect.c | 17 +-- 12 files changed, 1200 insertions(+), 560 deletions(-) create mode 100644 src/plf2ops.c 0001-Support-arbitrary-storage-of-2D-user-data.patch.gz Description: GNU Zip compressed data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] -bg with alpha gives strange overlay effect on x02c
I just ran this... x02c -dev xcairo -bg ff_0.3 ...and noticed on the second plot I can see through to the first plot. I don't think I have any other non-cairo, alpha-capable drivers built so I can't tell if it's cairo-related or more general. Here are the devices I have available... Plotting Options: 1 xwin X-Window (Xlib) 2 tk Tcl/TK Window 3 ps PostScript File (monochrome) 4 pscPostScript File (color) 5 xfig Fig file 6 null Null device 7 tkwin New tk driver 8 memUser-supplied memory device 9 aqtAquaTerm (Mac OS X) 10 psttf PostScript File (monochrome) 11 psttfc PostScript File (color) 12 svgScalable Vector Graphics (SVG 1.1) 13 xcairo Cairo X Windows Driver 14 pdfcairo Cairo PDF Driver 15 pscairoCairo PS Driver 16 svgcairo Cairo SVG Driver 17 pngcairo Cairo PNG Driver 18 extcairo Cairo External Context Driver Can someone with qt devices please try this? Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -bg with alpha gives strange overlay effect on x02c
Thanks for confirming this, Alan! On Mar 10, 2010, at 8:09 , Alan W. Irwin wrote: -dev qtwidget does not have this problem, and neither does -dev svg. (For the latter, you must use the familying option -fam which will generate two files corresponding to the two pages.) I don't know how qtwidget does it's plots, so I can't comment on that, but for svg, I think the fact that the second plot comes out OK is not so conclusive. The pdfcairo driver also produces a two page output file. Page 2 of that file looks OK, too, but it is a separate page after all. I'm not really sure how to interpret alpha for the background of a GUI window. What's behind the background to see through too? For graphics files (e.g. .png or .svg) they might be overlaid on something else so background transparency there is more intuitive. Perhaps if the background is non-opaque, GUIs could draw an opaque checkerboard backbackground (like the gimp does) before drawing the non-opaque background? Or maybe the GUI widgets being rendered into have their own alpha channel and could therefore be layered in a way that would give the background's alpha channel an obvious meaning? In this case, the GUI widget would need to be cleared before drawing the non-opaque background of a subsequent plot. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -bg with alpha gives strange overlay effect on x02c
On Mar 10, 2010, at 11:05 , Alan W. Irwin wrote: There are already some neat transparent background effects being deployed on the desktop (e.g., if you move a KDE GUI it becomes transparent so you can see underneath it) that show this is possible. I think this might be a property of the window manager rather than the window itself or the application displaying in the window. Thus, for example, I assume some file viewers may already allow transparent background options of their own so that when that is combined with a transparent PLplot background you could see through to the application below. Similarly, I assume there are GUI options for GNOME and KDE to allow transparent GUI backgrounds. If there is a window manager independent way of making a window's background transparent then it would be great to use. Not sure how this would work on MS Windows vs X Windows. But I have not researched any of this yet. Me neither! :-) Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plsetopt( -h, NULL ) exits process
plsetopt(-h,NULL) exits the process and doesn't even show any help. The -v option does the same thing (i.e. exits the process without any output). I think this could be fixed relatively easily and without any negative impact by changing opt_h and opt_v (in src/ plargs.c) to return 0 (instead of the exit-inducing 2) if mode_quiet is enabled (else return the exit-inducing 2 as it does now). Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Prevent plsetopt from exiting on -h and -v
Changes opt_h and opt_v handlers to prevent -h and -v options from
calling exit() if PL_OPTION_QUIET is set.
---
src/plargs.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/plargs.c b/src/plargs.c
index cbacadf..4b0e405 100644
--- a/src/plargs.c
+++ b/src/plargs.c
@@ -1474,9 +1474,12 @@ static int
opt_h( const char *opt, const char *optarg, void *client_data )
{
if ( !mode_quiet )
+{
Help();
+return 2;
+}
-return 2;
+return 0;
}
/*--*\
@@ -1490,9 +1493,12 @@ static int
opt_v( const char *opt, const char *optarg, void *client_data )
{
if ( !mode_quiet )
+{
fprintf( stderr, PLplot library version: %s\n, VERSION );
+return 2;
+}
-return 2;
+return 0;
}
/*--*\
--
1.7.0
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Plot gradient visual cue only if DEBUG is defined
--- src/plgradient.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/plgradient.c b/src/plgradient.c index d864d0a..57ab581 100644 --- a/src/plgradient.c +++ b/src/plgradient.c @@ -145,9 +145,11 @@ c_plgradient( PLINT n, PLFLT *x, PLFLT *y, PLFLT angle ) } plP_plfclp( xpoly, ypoly, n, plsc-clpxmi, plsc-clpxma, plsc-clpymi, plsc-clpyma, plP_gradient ); +#ifdef DEBUG /* Plot line corresponding to gradient to give visual * debugging cue. */ plline( NGRAD, dxgrad, dygrad ); +#endif } } -- 1.7.0 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Fix plfimage function
On Mar 5, 2010, at 8:03 , Alan W. Irwin wrote: Thanks for that suggestion for avoiding strcat whose effect depends on octave version. (Ugh!) To be fair, the 3.0.1 behavior was arguably a bug since it was not Matlab-compatible behavior and I think Matlab compatibility is one of Octave's goals. This suggestion works for me as well with octave-3.0.1. Therefore, I have committed this change (revision 10846) even though my knowledge of octave is minimal. Great! Thanks! Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Fix plfimage function
On Mar 4, 2010, at 21:46 , David MacMahon wrote: I'm looking into some possible conflicts between system tcl/tk and macports tcl/tk... Sure enough. I was inadvertently using a mix of system (Mac OS X 10.4) tcl (8.4) and MacPorts tcl (8.5). I've remedied the situation by using only the MacPorts one and now things work better for the non- interactive tests. For the interactive tests, I get problems with some of the tk examples. I think it has to do with plbop/pleop vs plinit/plend when using plserver. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Fix cmake warning about mismatched if/endif.
---
examples/CMakeLists.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
index 899795a..b7eddd3 100644
--- a/examples/CMakeLists.txt
+++ b/examples/CMakeLists.txt
@@ -771,7 +771,7 @@ if(BUILD_TEST)
list(APPEND targets_examples_tk test_tk_04)
endif(ENABLE_itk)
- endif(ENABLE_tk)
+ endif(ENABLE_tk AND PLD_tk)
if(targets_examples_tk)
list(APPEND interactive_targets_LIST ${targets_examples_tk})
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Underscore and backslash
I noticed that underscores and backslashes in plmtex text appear as centered dots with the xwin driver, but as underscores and backslashes with the xcairo driver. I also notice that these two characters appear as centered dots with both drivers in example 6, which uses plploin... http://plplot.sourceforge.net/examples.php?demo=06 The caret/circumflex character appears as a degree symbol, which is also problematic (IMHO), but at least it's consistent with PGPLOT... http://www.astro.caltech.edu/~tjp/pgplot/hershey.html http://www.astro.caltech.edu/~tjp/pgplot/figenc.ps I looked into where/how to rectify this, but I don't (yet) understand PLplot's text encoding and font handling well enough to make progress myself. Can anybody help me out here? Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Fix plfimage function
On Mar 4, 2010, at 17:30 , Alan W. Irwin wrote: On 2010-03-04 16:25-0800 David MacMahon wrote: octave Missing examples: 19 Differing postscript output : 28 29 Missing stdout : Differing stdout: 14 tcl Missing examples: Differing postscript output : 21 28 Missing stdout : Differing stdout: 21 Those are the expected results. The glass is 99.6 per cent full way to look at this is 99.6 per cent of our bindings/examples produce identical PostScript results to our C versions which is a terrific achievement. Yes, I agree! FWIW, the octave and tcl postscript output for x28 match (other than CreationDate). It looks like maybe those examples got left out during this set of changes... r10789 Propagate recent example 28 fixes to OCaml r10710 Propagate C changes for example 28 to the corresponding Lua example. r10709 Propagate C changes for example 28 to the corresponding Python example. r10708 Propagate C changes to example 28 to the corresponding f77 and f95 examples. r10699 Propagate C changes to example 28 to the corresponding C++, D, and Java versions. r10697 Commit prototype changes to the C example to improve the appearance of pages 2 and 3. These changes need to be propagated to all the remaining language examples. I ran make test_interactive, but it gets to... [ 97%] Built target test_c_xcairo [100%] Built target tk Generate C results for tk interactive device Testing subset of C examples for device tk x01c ...and then appears to hang there. I get an empty plserver window, but don't know what to do at that point, so I wait a while and then ctrl-c which stops the test sequence. Any pointers? However, you may want to put this Tk issue aside (-DENABLE_tk=OFF -DPLD_tk=OFF) for now and instead concentrate on testing your 2D patch for the non-Tk case now so we can move forward with that. Your choice as to what you do first. Either would be quite a help to us. I'm looking into some possible conflicts between system tcl/tk and macports tcl/tk... Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Problem with tick marks and tight ranges
On Mar 3, 2010, at 12:42 , Andrew Ross wrote: It should be fixed to stop plplot getting stuck in an infinite loop, but to be honest if you are really trying to plot such a small range then rounding errors are likely to occur with all the rest of the plotting code too. Getting plots with rounding errors is certainly better than getting a runaway process and no plots! :-) I'll add it to my list unless anyone else can provide a patch first. Great, thanks! Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Fix plfimage function
Hi, Alan, On Mar 3, 2010, at 12:05 , Alan W. Irwin wrote: For source trees with and without the patch time make -j4 -k test_noninteractive make_testnoninteractive.out time make -j4 -k test_interactive make_testinteractive.out I assume you would like, for example,... make time make -k test_noninteractive ...so that the running if the tests is timed rather than the build process. David, I think the current patch is the third correction to your 2D work (if you count the patch that changes example 8 to use the new API). To make Hazen's and my job easier, would you be willing to now send one comprehensive corrected patch concerning your arbitrary 2D data work to this list? This was the fourth correction (if you count the example 8 patch). Here are the subjects/captions of the five patches (first on is the main patch, other four are corrections)... Support arbitrary storage of 2D user data Make plgriddata call plfgriddata Add plfimage function Fix plfimage function Use plf2ops functions in examples/c/x08c.c Tonight I will rolls all of these patches into one patch that can be applied to svn/trunk and send it out. Would you be also willing to do the above tests on Mac OS X with and without your corrected patch? If so, and assuming there are no regressions please send me a column following the format in README.release describing the test. Yes, I will do this both to provide the results and to make sure no further corrections are needed. I think I still need to add a plfshades or plfshade1... Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Fix plfimage function
Hi, Alan, On Mar 3, 2010, at 18:35 , Alan W. Irwin wrote: On 2010-03-03 13:13-0800 David MacMahon wrote: [...] Tonight I will rolls all of these patches into one patch that can be applied to svn/trunk and send it out. Thanks. Would you be also willing to do the above tests on Mac OS X with and without your corrected patch? If so, and assuming there are no regressions please send me a column following the format in README.release describing the test. Yes, I will do this both to provide the results and to make sure no further corrections are needed. I think I still need to add a plfshades or plfshade1... Thanks. I've added plf2ops-enabled functions plfshade1() and plfshades(). plfshade() already exists, but it uses a different (and apparently unimplemented) defined technique so I left it alone (i.e. still using a user-supplied f2eval evaluator function and the different defined technique). Unfortunately, I did not get to run the comparative tests yet nor roll everything up into one big patch. I hope to get to this tomorrow. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Problem with tick marks and tight ranges
I think I've found a problem with tick marks and tight ranges. The tick marks seem to be drawn by starting at an initial tick position and then repeatedly incrementing the tick position by a delta value until the tick position advances out of range. If the window is setup for a tight y (or x) range, the magnitude of the non- zero delta value can be so small that tp+delta == tp (due to limited bits in the floating point mantissa) and so the incremental process never finishes and plenv (or plbox or, really, plaxes) never returns and CPU usage goes to 100%. It would be safer to calculate the number ticks to be drawn and then use an explicitly bounded for loop to draw exactly that many ticks at positions (initial_pos + i*delta). This problem should be repeatable by using one of these... plenv(0, 1, 1-1e-16, 1+1e-16, 0, 0); plenv(0, 1, 1e16, 1e16+10, 0, 0); Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plenv and plschr oddness
I've noticed some unexpected behavior with plschr and plenv. I modified x09c.c by adding this line... plschr(0.0, 0.5); ...immediately before the first plenv call in main (i.e. the plenv call for the Plot using identity transform plot). This plenv call draws the numeric labels for the X and Y ticks, and the above plschr call resulted in smaller text for that plot, which I expected. The unexpected (at least by me) behavior is that the next plot (i.e. the Plot using 1d coordinate transform plot) reverted back to the default character size. Even if I put a plschr call immediately before the second plenv call, the numeric labels on the second plenv call come out at the default size. In fact, I can't find a way to make the numeric labels drawn in subsequent plenv calls be anything other than the default size! I found a workaround: call plenv with axis=-1 (or -2) and subsequently call plschr and plbox to draw the numeric labels (and box). Can anyone shed light on why only the first plenv call respects earlier plschr calls? Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plGraphicsIn button field
I've been working on porting example 20 to Ruby. I notice when I'm dragging the crosshairs around to select a rectangle that sometimes the button field of the plGraphicsIn structure will get set to a large value (e.g. 0x7b8000). Although I haven't seen this behavior with x20c, I think that maybe there is a problem in drivers/xwin.c. In MasterEH(), the event is dispatched according to its type. The dispatch for the MotionNotify is... case MotionNotify: if ( event-xmotion.state ) ButtonEH( pls, event ); /* drag */ MotionEH( pls, event ); The (postulated) problem is that this can call ButtonEH, which calls LookupXButtonEvent, which treats the XEvent as an XButtonEvent when in fact it is an XMotionEvent. LookupXButtonEvent assigns the plGraphicIn's button field from the button field of the mis-cast XEvent structure. In the case of an XMotionEvent, I think this ends up treating the is_hint char field and subsequent mystery bytes as an unsigned int, leading to the bogus values I am seeing. Presumably. the memory usage of x20c is such that these extra mystery bytes are always zero so this problem never really manifests itself. More info about these XEvents can be seen here... http://www.xfree86.org/current/XButtonEvent.3.html I'm not sure whether this is a real problem nor how to deal with it if it is. For now I am ignoring it and moving on, but I thought I'd mention it in case anyone else has any thoughts or ideas about it. Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Fix plfimage function
This fixes a parameter ordering problem in plfimage's call to the minmax
operator function.
---
src/plimage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/plimage.c b/src/plimage.c
index bfa5ef7..d18b5cf 100644
--- a/src/plimage.c
+++ b/src/plimage.c
@@ -363,7 +363,7 @@ plfimage( PLF2OPS idataops, PLPointer idatap, PLINT nx, PLINT ny,
/* Find the minimum and maximum values in the image. Use these values to
* for the color scale range. */
-idataops-minmax( idatap, nx, ny, data_max, data_min );
+idataops-minmax( idatap, nx, ny, data_min, data_max );
if ( xmin == Dxmin xmax == Dxmax ymin == Dymin ymax == Dymax )
{
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ruby bindings
Hi, Andrew, Thanks for your comments. Ideally I'd like somehow to support both a Ruby-centric installation (i.e the .gem file) as well as non-Ruby- centric installations (e.g. apt/yum/port/whatever). Alan's analysis (showing that most people install plplot binaries via a package manager) got me wondering about how most people install Ruby extensions. I've always done it via the gem command, but I know MacPorts has a bunch of rb-xyzzy ports that can be installed, so maybe people install Ruby extensions that way more often than I imagine. To tell the truth, I wouldn't be able to install a non-gem Ruby extension manually without looking up how to do it! :-) One nice thing about the gem based install is that it is very easy for non-admin users to install gems under their home directories so they need not bother the admins with installing gems in system directories (but they can if they want to, of course). I imagine most package managers let non-admin users do that too, but I'd be surprised if it were so easy as a non-admin gem based installation. How does Debian package up Ruby extensions? For example, is there a rails package? Thanks again, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Ruby bindings
On Feb 27, 2010, at 14:47 , Alan W. Irwin wrote: On 2010-02-26 14:09-0800 David MacMahon wrote: As you all know by now, I'm working on Ruby bindings to PLplot. I am (still) almost ready for a first release. There's always a few more things! :-) You may have done this already, but I highly recommend that you implement the standard set of 31 examples in ruby. Yes, I am fairly far along with porting the examples to Ruby. There are a few rough edges, but I basically have examples 1-16, 18, 21-25 already working under Ruby. Example 17 is the strip chart one and I just haven't gotten to those functions yet. This is also the case for example 19 (the map functions). I am nearing completion of example 20 (plimage and plimagefr). I haven't started porting the rest, but I think examples 26,27,28 should be straightforward. I haven't done the time functions yet (haven't figured out how they relate to TAI, UTC, JD, etc.) so example 29 is still a TODO. I think examples 30 and 31 should be very easy once I get to them. The test_diff_psc target (which is a subset of the test_noninteractive target) has been implemented to compare Postscript results from all our official bindings with Postscript results from the standard C examples. This has proved to be a powerful tool to diagnose even subtle bugs in the bindings, but complete coverage of the API does require implementing the complete standard set of examples in each set of bindings. Sounds very useful! Thanks for bringing this to my attention. The above suggestion pertains regardless of whether you are going to donate your ruby bindings to PLplot or not. I certainly plan on donating them, but I'm not sure the best channel. Ruby has an excellent package manager, RubyGems, that makes downloading and installing extensions very easy (provided the requisite libraries are already installed). I would like for people to be able simply to run gem install plplot to install the Ruby bindings to PLplot (again assuming they have the PLplot libraries already installed). This would be building upon the binary distros of PLplot (such as those that have been recently discussed on this list). This just means that I need to publish a gem file on one of the standard RubyGems distribution sites (formerly rubyforge.org, but I think now gemcutter.org), but it doesn't say anything about where the source code for the Ruby bindings will ultimately live. Right now the source code lives in a git repo (separate from my git svn clone of the PLplot Subversion repo) on my laptop, but clearly it needs to be moved elsewhere once the bindings are released. After all, we can disable the ruby bindings by default until they build and test without issues, and thus they won't interfere with normal use of PLplot. Furthermore, there will be plenty of opportunity for you to send patches in later to implement required bindings changes and add more standard example implementations. In fact, I would positively encourage such maintenance. :-) Thanks for this encouragement! I still want to polish things up a little more before I release the Ruby bindings, but they are getting quite close to a releasable state. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -dev tk fails to work for install tree
On Feb 26, 2010, at 9:27 , Alan W. Irwin wrote: On 2010-02-25 15:13-0800 Alan W. Irwin wrote: Want to give git-bisect a try for this case? If so, here are the instructions for reproducing the error. All good ideas are copied. From a google search for svn bisect, it appears there is now a perl svn-bisect script to do svn bisect plus an official svn-bisect script in the works. I plan to try the perl script for now to see how fast I can come up with the answer for which revision caused this regression. Great! I'll try it with git, but I'm not sure how soon I'll be able to get to it. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
On Feb 22, 2010, at 10:37 , David MacMahon wrote: On Feb 22, 2010, at 6:42 , Andrew Ross wrote: I would like to have a thorough comparison of the time difference. This should include a large data case as well where timings might be more important. The lena image might be one suitable case. As I said earlier, I share this concern. My 100x test was done using the Lena image, but I agree that further analysis would be reassuring (or not as the case may be). I have done some further performance testing using x20c (the test using the Lena image). The results are slightly different, but still very encouraging. I think my previous x20c loop tests were not a valid comparison because it turns out I was looping on a call to plimage, which I had not yet changed to call the plf2ops version named plfimge. I had created plfimagefr, but I had not created plfimage. So I think my big x20c loop test was not really exercising new code. I have since created plfimage (patch forthcoming) and modified x20c.c to loop 2000 times on each of the two calls to plimage that plot only Lena's eyes (one call plots only the eyes in their normal size/ position, the other call plots them zoomed in). This subset plotting involves copying parts of the 2D data array so it definitely makes use of the new plf2ops code. I ran the modified x20c test three times using an unpatched libplplot with NO plf2ops stuff added and three times using a patched libplplot with the plf2ops stuff added. Here are the results from my (now old) MacBook Pro laptop... WithOUT plf2ops --- 2m 22.1s 2m 21.8s 2m 21.9s WITH plf2ops 2m 23.2s 2m 23.1s 2m 23.2s So the plf2ops version took about 1.2 seconds longer than the non- plf2ops version or approximately a 1.5% performance hit. It would be great is someone else could repeat this test and corroborate (or not) the results. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] -dev tk fails to work for install tree
Hi, Alan, On Feb 25, 2010, at 13:47 , Alan W. Irwin wrote: I am not sure whether it is a regression caused by the embedded blank fix or a regression caused by a previous -dev tk fix, but -dev tk (as run by the test_interactive target) used to work fine for the CMake-based build system for the installed examples. I can't help you with the tk problem, but wanted to note that this kind of situation is exactly why git bisect was created: finding the exact commit that breaks something. You start off by giving git bisect the last known good version and the currently known bad version and it checks out a version in the middle. You build/test that version, tell git bisect whether it is good or bad, and it then checks out a version in the middle of the updated known-good/ known-bad range. The process repeats until the exact change which introduces the problem is identified. If you can automate/script the build/test steps, then git can iterate to the end without any intervention! Sorry for the off-topic advocacy, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] x23c -dev xwin
I thought x23c -dev xwin used to work for me, but now it appears to be broken. All pages work fine for -dev xcairo. I am using a freetype-enabled libplplot build, but the xwin driver only works for the first page (and even then the title text that appears is 0x10PLplot Example 23 - Greek Letters). Any ideas on what could be wrong? Am I mis-remembering that x23c - dev xwin used to work for me? Maybe I'm confusing it with x06c and x07c (which do still work fine for me using the xwin driver)? Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] x23c -dev xwin
Thanks, Alan, On Feb 23, 2010, at 14:48 , Alan W. Irwin wrote: No. -dev xwin is pure Hershey (just like all our traditional devices). To explain further, we had a first generation of unicode font support via plfreetype.c (e.g., gd.c which is now deprecated because of the limitations of this approach), but now we are relying on external libraries (e.g., the pango/cairo stack of libraries and Qt stack of libraries at our run time and the svg libraries after our run time when the svg file result with embedded unicode strings is displayed) to properly support unicode fonts. The only non-unicode and non-Hershey font we support are the Type 1 fonts for the ps.c device driver, but those are interfaced internally with a unicode to type 1 translation table so the overall ps.c font approach is similar to that done for the svg, cairo, and qt devices, but with the very limited set of glyphs that are available for Type 1 fonts. Are the USE_FREETYPE and other related cmake variables all deprecated along with the gd driver? Are there any other bitmapped dirvers that use it? Is there any way to query the driver's unicode capability (or lack thereof)? Yes. softw...@raven grep dev_unicode drivers/* drivers/aqt.c:pls-dev_unicode = 1; /* wants text as unicode */ Is there a way API to query this info via the? It seems like it would save some confusion if x23c bailed out with an informative message if/when it detects that the user has selected a non-unicode aware driver. Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
Hi, Andrew, Thanks for your review and thoughtful comments! Here are some replies. On Feb 22, 2010, at 6:42 , Andrew Ross wrote: 1) Using structures of function pointers in C is clearly the way to implement this, but it might give us headaches for some languages where either function pointers or structures are not available. I thought about this point and hoped to alleviate any problems by not exposing the actual structures themselves. Instead I provide functions that return pointers to said structures. Languages that do not support function pointers or structures should at least be able to map the pointer to structure return values of these functions to integers. 2) There are quite a few callback functions implemented. In most cases we only need a get / set, although I can see that having the other operators is (slightly) more efficient in that only one call is required. Does this make a noticeable difference? Even for functions that require only set or get, I chose to pass in a pointer to the structure to keep the API consistent. Functions that accept a pointer to a plf2ops structure yet use only one function pointer from that structure can simply declare a local function pointer and initialize it from the desired member of the structure. 3) Talking of efficiency, I worry that this introduces a large additional level of complexity for a rather specialist set of cases where odd data storage methods are used. I am slightly relieved by David's comments, but I would like to have a thorough comparison of the time difference. This should include a large data case as well where timings might be more important. The lena image might be one suitable case. As I said earlier, I share this concern. My 100x test was done using the Lena image, but I agree that further analysis would be reassuring (or not as the case may be). The test should also multi-language tests to see if not copying large amounts of data around is quicker than having lots of callbacks. Sounds like a good idea. I think copying/transposing data will lose out because either it requires dynamic allocation in the bindings or puts the onus of copying/transposing the data onto the user. 4) It terms of applications there are two big uses I can see a) To simplify the langauge bindings (which is mostly hidden from the user). b) To allow the user to use odd data storage methods more efficiently. I can think of some interesting uses here like plotting a subset or subsample of an array. It would be nice to include examples of this. This is potentially a much more generally useful outcome of this from a user point of view. I completely agree with these points. As I mentioned in an earlier email, I think 4b is a reason to consider implementing something similar for 1D data (e.g. to allow plotting of a single column of a 2D array)! 5) Given the current mishmash of methods for dealing with 2-d arrays then I would like to see this implemented consistently for all functions which take 2-d data. Of course we need to ensure backwards compatibility, but we should ensure the new interface is right from the start. I tried to make API of new functions as consistent as possible. If you see any places where consistency could be improved, please let me know. The patch under discussion should maintain 100% backwards compatibility; any case where it doesn't is a bug! To maintain backwards compatibility, I did not modify the API of any existing functions. This includes functions, such as plfcont, that already accept a pointer to an evaluator function. Those functions are admittedly in an in between state. Perhaps new plf2ops variants of these functions could be created and the existing forms deprecated. Sorry this is rather late in the discussion! IMHO, your content more than makes up for any delay! Thanks again, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] PLFLT_MAX and float.h
I notice plplot.h defines PLFLT_MAX to be either FLT_MAX or DBL_MAX depending on whether PL_DOUBLE (or DOUBLE) is defined. It does not, however, include float.h which is where (at least on my Mac) FLT_MAX and DBL_MAX appear to be defined. For now, I will just add #include float.h to my source file that uses PLFLT_MAX, but shouldn't plplot.h include it for me? Thanks, Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plshade question
On Feb 18, 2010, at 9:14 , Alan W. Irwin wrote: I left out your other questions because I am confused on those issues as well. However, assuming you get them figured out, I would appreciate it if you took some additional time to update the relevant docbook documentation to help relieve everybody's confusion on these matters. I'll take a crack at it if/when I get to an appropriate level of understanding. I can help you out a bit with this one. There is an example of how defined is used in the C version of example 16. And, FWIW, I think we should have adopted a more general API for defined. However, I guess nobody cares too much about it because of its limitations. For example, the defined part of example 16 looks pretty good at normal resolution, but you get a real mess at lower resolutions. Thanks for the pointer. Just to make this more searchable in the archives, use of plshade's defined feature is only demonstrated when giving x16c the -exclude option. Compare the output of these two commands... x16c -dev xwin -exclude x16c -dev xwin -exclude -nx 10 -ny 10 Thus, I don't think there is any language interface that currently propagates what C does with defined, Actually, the ocaml bindings seem to support this concept. and I suggest you skip it for Ruby as well. Too late! :-) I've already borrowed from the approach taken in the ocaml bindings. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plshade question
plshade has three groups of parameters that I am having a hard time understanding: 1) xmin,xmax,ymin,ymax - Define the 'grid' coordinates. The data a [0][0] has a position of (xmin,ymin), a[nx-1][0] has a position at (xmax,ymin) and so on. 2) defined - User function specifying regions excluded from the shading plot. This function accepts x and y coordinates as input arguments and must return 0 if the point is in the excluded region or 1 otherwise. This argument can be NULL if all the values are valid. 3) pltr, pltr_data parameters which translate 2D data indices into world coordinates. I think I understand pltr,pltr_data since those are also used in the plcont functions, but I have questions about the other two groups. What is the purpose of explicitly specifying xmin,xmax,ymin,ymax? Based on the comments/documentation, it sounds like xmin,ymin could be determined by passing (0,0) to pltr and xmax,ymax could be determined by passing (nx-1,ny-1). At least that's the case for pltr0 and pltr1 (with monotonic x and y grid axes), but for pltr2 the mapping from 2D data indices to world coordinates seems arbitrary (e.g. polar to rectangular) so determining xmin etc from pltr is not really viable. While that sounds like a valid reason for specifying xmin etc explicitly, the code for plshade looks like it uses (xmax- xmin)/nx to determine dx (and likewise for dy), which seems to assume a linear mapping from i and j indices to x and y world coordinates, so I'm back to being confused. Since defined does not have a corresponding user data pointer, it seems that whether a point is defined or not must be determinable solely from the x,y coordinates themselves and not from the 2D data values (or accompanying data valid flags array). Is the primary intent of this to limit the region that is shaded (kind if like kx,lx,ky,ly for plcont, but in world coordinates rather than 2D data indices)? FWIW, these questions arose because I'm trying to figure out the best way to deal with these parameters in my Ruby bindings. Thanks, Dave -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
Hi, Alan, On Feb 16, 2010, at 0:07 , Alan W. Irwin wrote: Dave, I thank you for your implementation work. It takes courage to be the first to implement something that is going to be thoroughly (I hope) reviewed by others, and I thank you for that courage! At the risk of sounding like a mutual thank you fest, thank you for your leadership in overseeing and contributing to the ongoing development of PLplot. It is somewhat bittersweet that my specific motivation for supporting the arbitrary storage of 2D data has been nullified (see other pltr0f/ pltr2f thread) yet my desire for this capability remains. IOW, I don't need/require this patch anymore but I still think it adds value and is well worthwhile. :-) Dave -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
On Feb 16, 2010, at 9:24 , Alan W. Irwin wrote: From the description, it sounds like the current 2D array API has been reimplemented as a wrapper for the Dave's new 2D array API. So just testing the normal examples with the current 2D array API should indirectly exercise the new API. Yes. To be very clear, my intent is that this patch NOT change the API of any existing function. If anyone finds that it does, please let me know and I will fix it. The patch should only add new things (structures, functions, etc.) and move pltr2f() from the f77 and f95 bindings into libplplot proper. It turns out that there are really two current 2D array APIs. Some of the PLplot functions already support the concept of arbitrary storage of 2D data (e.g functions relating to plcont, plshade, plvect). My patch neither changes the API of these functions nor introduces new variants of them. These existing functions still accept a single function pointer for *accessing* (aka evaluating) the arbitrarily stored 2D data rather than a pointer to a structure of function pointers for *operating* on said data (accessing the data is one of several supported operations). Other PLplot functions that work with 2D data arrays, such as plplot3d, plsurf, and plmesh, current;y (i.e. pre-patch) require that the 2D data be stored in a particular form. My patch does not change the API of these functions, but it does introduce new variants of them that accept a 2D data array as a PLPointer plus a pointer to a structure of function pointers for operating on the data. The patch also replaces the implementation of the existing functions to forward their arguments to the new corresponding variant with a suitable pointer to a set of operator functions. In theory, the existing functions could be written as preprocessor macros that invoke the new variants, but obviously that would not work for existing code that expects the existing functions to exist in the library as callable symbols. The newly created variants are really modified and renamed versions of the existing functions. Other than the 2D data operations, the implementations themselves should remain unchanged. However, I strongly second Arjen's plea to at least convert one example (example 16?) to using the new 2D array API directly so that all the issues of porting it to the various languages (including perl/ PDL) can be worked out. Since the plshade functions have not changed dramatically, I think examples 8 (plot3d), 20 (plimage), and/or 21 (plgriddata) might be better choices to port to the new API. Examining how the post- patch versions of the existing functions call into their new variants would show how these changes would look. I would be happy to do this for one of these examples (requests please!), but it might be instructive for others to try it as well; it should be very straightforward. My primary concern about the patch is the impact it will have (if any) on the performance of calls involving 2D data arrays. I added a loop to x20c.c such that it calls into plimage 100 times. I ran it with pre-patch and post-patch builds using the null driver and found no significant performance change, so I have some confidence that it does not make things horribly worse, but I still worry (a little) about potential negative impacts to performance. Thanks, Dave -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Use plf2ops functions in examples/c/x08c.c
Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays. Shows how to do surface plots with the following
four types of 2D data arrays:
1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */
---
examples/c/x08c.c | 32 +++-
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/examples/c/x08c.c b/examples/c/x08c.c
index 211aa32..7a84876 100644
--- a/examples/c/x08c.c
+++ b/examples/c/x08c.c
@@ -26,6 +26,10 @@
#include plcdemos.h
+/* plexit not declared in public header! */
+PLDLLIMPEXP void
+plexit( const char *errormsg );
+
#define XPTS35 /* Data points in x */
#define YPTS46 /* Data points in y */
@@ -121,7 +125,8 @@ int
main( int argc, const char *argv[] )
{
int i, j, k;
-PLFLT *x, *y, **z;
+PLFLT *x, *y, **z, *z_row_major, *z_col_major;
+PLfGrid2 grid_c, grid_row_major, grid_col_major;
PLFLT xx, yy, r;
PLINT ifshade;
PLFLT zmin, zmax, step;
@@ -145,6 +150,16 @@ main( int argc, const char *argv[] )
y = (PLFLT *) calloc( YPTS, sizeof ( PLFLT ) );
plAlloc2dGrid( z, XPTS, YPTS );
+z_row_major = (PLFLT *) malloc( XPTS * YPTS * sizeof( PLFLT ) );
+z_col_major = (PLFLT *) malloc( XPTS * YPTS * sizeof( PLFLT ) );
+if( !z_row_major || !z_col_major )
+plexit( Memory allocation error );
+
+grid_c.f = z;
+grid_row_major.f = (PLFLT **)z_row_major;
+grid_col_major.f = (PLFLT **)z_col_major;
+grid_c.nx = grid_row_major.nx = grid_col_major.nx = XPTS;
+grid_c.ny = grid_row_major.ny = grid_col_major.ny = YPTS;
for ( i = 0; i XPTS; i++ )
{
@@ -169,17 +184,22 @@ main( int argc, const char *argv[] )
if ( rosen )
{
z[i][j] = pow( 1. - xx, 2. ) + 100. * pow( yy - pow( xx, 2. ), 2. );
+
/* The log argument may be zero for just the right grid. */
if ( z[i][j] 0. )
z[i][j] = log( z[i][j] );
else
z[i][j] = -5.; /* -MAXFLOAT would mess-up up the scale */
+
}
else
{
r = sqrt( xx * xx + yy * yy );
z[i][j] = exp( -r * r ) * cos( 2.0 * M_PI * r );
}
+
+z_row_major[i * YPTS + j] = z[i][j];
+z_col_major[i + XPTS * j] = z[i][j];
}
}
@@ -213,22 +233,22 @@ main( int argc, const char *argv[] )
if ( ifshade == 0 ) /* diffuse light surface plot */
{
cmap1_init( 1 );
-plsurf3d( x, y, z, XPTS, YPTS, 0, NULL, 0 );
+plfsurf3d( x, y, plf2ops_c(), (PLPointer)z, XPTS, YPTS, 0, NULL, 0 );
}
else if ( ifshade == 1 ) /* magnitude colored plot */
{
cmap1_init( 0 );
-plsurf3d( x, y, z, XPTS, YPTS, MAG_COLOR, NULL, 0 );
+plfsurf3d( x, y, plf2ops_grid_c(), (PLPointer)grid_c, XPTS, YPTS, MAG_COLOR, NULL, 0 );
}
else if ( ifshade == 2 ) /* magnitude colored plot with faceted squares */
{
cmap1_init( 0 );
-plsurf3d( x, y, z, XPTS, YPTS, MAG_COLOR | FACETED, NULL, 0 );
+plfsurf3d( x, y, plf2ops_grid_row_major(), (PLPointer)grid_row_major, XPTS, YPTS, MAG_COLOR | FACETED, NULL, 0 );
}
else /* magnitude colored plot with contours */
{
cmap1_init( 0 );
-plsurf3d( x, y, z, XPTS, YPTS, MAG_COLOR | SURF_CONT | BASE_CONT, clevel, nlevel );
+plfsurf3d( x, y, plf2ops_grid_col_major(), (PLPointer)grid_col_major, XPTS, YPTS, MAG_COLOR | SURF_CONT | BASE_CONT, clevel, nlevel );
}
}
}
@@ -238,6 +258,8 @@ main( int argc, const char *argv[] )
free( (void *) x );
free( (void *) y );
plFree2dGrid( z, XPTS, YPTS );
+free( (void *) z_row_major );
+free( (void *) z_col_major );
plend();
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
Hi, Alan, On Feb 10, 2010, at 23:01 , Alan W. Irwin wrote: On 2010-02-10 21:57-0800 David MacMahon wrote: I wouldn't miss pltr0f if both its declaration and definition were in the FORTRAN bindings only, but I would very much miss pltr2f! Why? Do you have some non-Fortran use for it? I would prefer to keep definitions used in our Fortran bindings in sccont.c. But that assumes pltr0f and pltr2f will be used just for the Fortran bindings which is why I am asking the above question. Yes, I have a non-Fortran (see the P.S.) use for pltr2f. I'll describe my specific non-Fortran need for this function (which might turn out not to be needed after all as you'll read below) and then explain why I think there is a general usefulness for it (regardless of whether my specific need still exists). Sorry for the length of this reply, but it covers more ground than just where these two functions should live. The Ruby PLplot bindings I'm working on utilize the Ruby NArray package for data storage. The NArray package (http:// narray.rubyforge.org/) provides a Ruby interface to multi-dimensional arrays of native data types along with some numeric processing capabilities, kind of like Numpy for Python. I had been thinking that it stores its data in column-major order, but while looking into it further to answer your question I have since discovered that it stores data in row-major order but reverses the ordering of the dimensions (and therefore indices). From http://narray.rubyforge.org/ SPEC.en: The order of Matrix dimensions is opposite from the notation of mathematics: a_ij = a[j,i]. From a plotting perspective, column-major order is more or less equivalent to row major order with reversed dimensions, but when it comes to matrix multiplication it's entirely different. As readers of this list know, I have been working on supporting arbitrary storage of 2D data. My primary motivation for doing this was to access the NArray 2D data via a pointer to data in column- major order. Since the data really are in row-major order with the dimensions reversed, this approach allows one to index the data more naturally (i.e. a[i,j] rather than the prescribed-though-backwards- seeming a[j,i]) at the expense of mistreating the data as being unintentionally transposed. I now think I should revert back to using the prescribed-though-backwards-seeming dimensioning/indexing of NArray, thereby eliminating my need for pltr2f. Even though my specific use of pltr2f is no longer needed, I still think it is useful to support 2D data that are in column-major order even in non-Fortran languages. Plotting libraries exist to plot data. Data come from various sources in various formats. IMHO, a plotting library that can work with multiple (even arbitrary) data formats is more user friendly than one which requires users to copy their non-conformant data into (one of) the conformant format(s). So I still think that supporting arbitrary storage of 2D data is a good thing. Moving pltr2f into libplplot seems like a step in that direction and my forthcoming patch will finish providing PLplot with that ability. I wonder if pltr2f could be re-written as a call to pltr2p with indices and dimensions reversed. Dave P.S. Here's an interesting little footnote about FORTRAN vs Fortran... http://en.wikipedia.org/wiki/Fortran#cite_note-0 -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
On Feb 11, 2010, at 14:15 , Alan W. Irwin wrote: Of course, all of this is just a formal API breakage because in practice both libplplotf77cd and libplplotf95cd depend on libplplotd so there should not be an API breakage for the combination, but I think we should observe these API formalities for the (so)versions of libplplotf77cd and libplplotf95cd. Yes, I hadn't considered that. I think this would be a good idea since (I think) it would prevent one from linking a post-patch libplplotfXXcd with a pre-patch libplplotd (which would not have any pltr2f between them) or a pre-patch libplplotfXXcd with a post- patch libplplotd (which would have pltr2f multiply defined). Whatever the final disposition of these two functions, I still think it would be good to make plplot.h and libplplotd consistent regarding them. I don't feel qualified to decide about this small patch so I am willing to go along with whatever the rest of the core developers here decide (especially Maurice who is qualified and who was encouraging about your original ideas on arbitrary 2D storage), but it appears to me this small patch is philosophically tied up with the ideas behind your big patch (or probably patch series) implementing arbitrary 2D storage. So perhaps it would be best to make this small patch part of that patch series so that your implementation of arbitary 2D storage could be evaluated when that implementation is completely done. I agree. Thanks to git rebase -i I can easily merge (and even later break apart) these patches. I will combine this patch in with my bigger patch. I will try to make time to send it out tonight or tomorrow for review. Thanks, Dave -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
Hi, Hazen, On Feb 10, 2010, at 18:02 , Hazen Babcock wrote: David MacMahon wrote: Moves the definitions of pltr0f and pltr2f (both declared in plplot.h) from the sccont.c files of the FORTRAN bindings into plcont.c. Could you elaborate briefly on what problem this patch solves? It moves the definition (i.e. implementation) of these functions into libplotd so that programs that include plplot.h (which already contains the declaration of these functions) and use these functions will link successfully. It seems not so great to have functions declared in plplot.h without having a definition of them in the corresponding library. Try this... $ grep '^pltr' include/plplot.h pltr0( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr1( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr2( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr2p( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, PLPointer pltr_data ); pltr0f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data ); pltr2f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data ); $ nm tmp/src/libplplotd.dylib | grep pltr d6cb T _pltr0 e2cd T _pltr0f d6e8 T _pltr1 d85c T _pltr2 e2ff T _pltr2f dda7 T _pltr2p I have this thread's patch applied so I see definitions in libplplotd for all six pltr* functions declared in plplot.h. If you do the same without this patch applied, you will only have four pltr* functions in libplplotd. An alternative fix would be to move the declarations from plplot.h into the FORTRAN bindings (where these functions were defined before this patch) . I wouldn't miss pltr0f if both its declaration and definition were in the FORTRAN bindings only, but I would very much miss pltr2f! Hope this clarifies things, Dave -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Fix typo in QHULL_RPATH variable name
Fixes a typo in the QHULL_RPATH variable name. It was being referenced
as QHULL_PATH (missing the 'R') in src/CMakeLists.txt, which led to an
empty -L in the output of pkg-config --libs plplotd.
---
src/CMakeLists.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 257e8a4..deade81 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -214,7 +214,7 @@ if(HAVE_QHULL)
if(QHULL_RPATH)
set(
libplplot${LIB_TAG}_LINK_FLAGS
- ${libplplot${LIB_TAG}_LINK_FLAGS} -lcsironn -L${QHULL_PATH} -lqhull
+ ${libplplot${LIB_TAG}_LINK_FLAGS} -lcsironn -L${QHULL_RPATH} -lqhull
)
else(QHULL_RPATH)
set(
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c
Moves the definitions of pltr0f and pltr2f (both declared in plplot.h)
from the sccont.c files of the FORTRAN bindings into plcont.c.
---
bindings/f77/sccont.c | 197 -
bindings/f95/sccont.c | 197 -
src/plcont.c | 197 +
3 files changed, 197 insertions(+), 394 deletions(-)
diff --git a/bindings/f77/sccont.c b/bindings/f77/sccont.c
index 5e96c23..3b277f9 100644
--- a/bindings/f77/sccont.c
+++ b/bindings/f77/sccont.c
@@ -25,203 +25,6 @@
#include plstubs.h
/*--*\
- * pltr0f()
- *
- * Identity transformation for plots from Fortran.
- * Only difference from C-language identity function (pltr0) is that the
- * Fortran paradigm for array index is used, i.e. starting at 1.
- \*--*/
-
-void
-pltr0f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data )
-{
-*tx = x + 1.0;
-*ty = y + 1.0;
-}
-
-/*--*\
- * pltr2f()
- *
- * Does linear interpolation from doubly dimensioned coord arrays
- * (row dominant, i.e. Fortran ordering).
- *
- * This routine includes lots of checks for out of bounds. This would
- * occur occasionally due to a bug in the contour plotter that is now fixed.
- * If an out of bounds coordinate is obtained, the boundary value is provided
- * along with a warning. These checks should stay since no harm is done if
- * if everything works correctly.
- \*--*/
-
-void
-pltr2f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data )
-{
-PLINT ul, ur, vl, vr;
-PLFLT du, dv;
-PLFLT xll, xlr, xrl, xrr;
-PLFLT yll, ylr, yrl, yrr;
-PLFLT xmin, xmax, ymin, ymax;
-
-PLcGrid *cgrid = (PLcGrid *) pltr_data;
-PLFLT *xg= cgrid-xg;
-PLFLT *yg= cgrid-yg;
-PLINT nx = cgrid-nx;
-PLINT ny = cgrid-ny;
-
-ul = (PLINT) x;
-ur = ul + 1;
-du = x - ul;
-
-vl = (PLINT) y;
-vr = vl + 1;
-dv = y - vl;
-
-xmin = 0;
-xmax = nx - 1;
-ymin = 0;
-ymax = ny - 1;
-
-if ( x xmin || x xmax || y ymin || y ymax )
-{
-plwarn( pltr2f: Invalid coordinates );
-
-if ( x xmin )
-{
-if ( y ymin )
-{
-*tx = *xg;
-*ty = *yg;
-}
-else if ( y ymax )
-{
-*tx = *( xg + ( ny - 1 ) * nx );
-*ty = *( yg + ( ny - 1 ) * nx );
-}
-else
-{
-ul = 0;
-xll = *( xg + ul + vl * nx );
-yll = *( yg + ul + vl * nx );
-xlr = *( xg + ul + vr * nx );
-ylr = *( yg + ul + vr * nx );
-
-*tx = xll * ( 1 - dv ) + xlr * ( dv );
-*ty = yll * ( 1 - dv ) + ylr * ( dv );
-}
-}
-else if ( x xmax )
-{
-if ( y ymin )
-{
-*tx = *( xg + ( nx - 1 ) );
-*ty = *( yg + ( nx - 1 ) );
-}
-else if ( y ymax )
-{
-*tx = *( xg + ( nx - 1 ) + ( ny - 1 ) * nx );
-*ty = *( yg + ( nx - 1 ) + ( ny - 1 ) * nx );
-}
-else
-{
-ul = nx - 1;
-xll = *( xg + ul + vl * nx );
-yll = *( yg + ul + vl * nx );
-xlr = *( xg + ul + vr * nx );
-ylr = *( yg + ul + vr * nx );
-
-*tx = xll * ( 1 - dv ) + xlr * ( dv );
-*ty = yll * ( 1 - dv ) + ylr * ( dv );
-}
-}
-else
-{
-if ( y ymin )
-{
-vl = 0;
-xll = *( xg + ul + vl * nx );
-xrl = *( xg + ur + vl * nx );
-yll = *( yg + ul + vl * nx );
-yrl = *( yg + ur + vl * nx );
-
-*tx = xll * ( 1 - du ) + xrl * ( du );
-*ty = yll * ( 1 - du ) + yrl * ( du );
-}
-else if ( y ymax )
-{
-vr = ny - 1;
-xlr = *( xg + ul + vr * nx );
-xrr = *( xg + ur + vr * nx );
-ylr = *( yg + ul + vr * nx );
-yrr = *( yg + ur + vr * nx );
-
-*tx = xlr * ( 1 - du ) + xrr * ( du );
-*ty = ylr * ( 1 - du ) + yrr * ( du );
-}
-}
-}
-
-/* Normal case.
- * Look up coordinates in row-dominant array.
- * Have to handle right boundary specially -- if at the edge, we'd
- * better not reference the out of bounds point. */
-
-else
-{
-xll = *( xg + ul + vl * nx );
-yll = *( yg
Re: [Plplot-devel] Plplot / Aquaterm / Snow Leopard problem
On Feb 7, 2010, at 9:15 , Hazen Babcock wrote: On Feb 6, 2010, at 8:31 PM, David MacMahon wrote: Have you actually experienced a crash due to this on Snow Leopard or are you expressing concern about a potential crash? I have not personally experienced this but a user of cl-plplot (the lisp bindings for Plplot) ran into this problem. If you are running a multi-threaded lisp process in a terminal window (a pretty common way to run lisp) and then try and use the aquaterm driver in Plplot the lisp process will crash with a Trace / BPT trap message. Pardon the blasphemy :-), but is there any way to invoke gnuplot (or pgplot) with its aquaterm driver in a similar manner from a multi- threaded lisp process? That should crash in a similar manner. I had been thinking in the back of my mind that maybe this was really related to the plargs bug on MacOSX that I recently sent in a patch for, but that crashed with a Bus Error message, but the Trace / BPT trap message seems inconsistent with that idea and consistent with the posting you initially referenced. This is probably not unique to the aquaterm driver. I think loading the xcairo driver also ends up loading CoreFoundation if it hasn't been loaded already, so that too would be subjected to this behavior. The user said that the xwin driver was ok, so maybe the xcairo driver will work as well? I believe the xwin driver does not use any libraries that ultimately depend on CoreFoundation, whereas the xcairo driver does. I expect that it will crash in the same way. Requiring that CoreFoundation be loaded from the main thread seems like a such a dlopen-unfriendly constraint that I suspect there is an easy way to ensure that it always happens that way. I suppose one could just always link one's application with CoreFoundation on MacOSX even if it doesn't use it unless/until a CoreFoundation dependent library is loaded. Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot / Aquaterm / Snow Leopard problem
Hi, Alan, On Feb 6, 2010, at 12:23 , Alan W. Irwin wrote: my understanding from http://en.wikipedia.org/wiki/Reentrant_(subroutine) is reentrancy implies thread safety. I'm not sure about that. I think a function could utilize thread local storage in a non-reentrant way (i.e. thread safe but not reentrant). Also if a function's reentrancy is dependent on a certain value/consistency of a global variable it would not necessarily be thread safe (i.e. somewhat reentrant, but not thread safe). Both of these cases are somewhat impure, but so is the real world! :-) If a function has no side effects and no external dependencies, then I would agree that it is both reentrant and thread safe. Having no side effects is relatively easy to verify/ensure, but having no external dependencies is harder since any parameter passed by reference represents an external dependency which could put the function's thread safety in the hands of the caller(s). Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot / Aquaterm / Snow Leopard problem
Hi, Hazen, On Feb 6, 2010, at 8:40 , Hazen Babcock wrote: The gist of it is this statement: if the CoreFoundation library's being initialized - perhaps as a result of that library being loaded as a dependent of some other library - and the current thread is not the initial thread, waste everyone's time by executing a breakpoint instruction. It sounds like this occurs when a multi-threaded program that is not linked with CoreFoundation dynamically loads a library that depends on CoreFoundation from within a thread other than the initial thread. So, if you try to use Plplot with the Aquaterm driver, which in turn will try to load the CoreFoundation library, in a threaded environment your process will crash. From my reading of the article excerpted above, this is true only if the program calls PLplot from a non-initial thread to load the aquaterm driver. And it's only true if executing the breakpoint instruction causes a crash. Maybe the breakpoint instruction gets trapped somehow so that the main thread can load CoreFoundation? Have you actually experienced a crash due to this on Snow Leopard or are you expressing concern about a potential crash? Perhaps the onus is on us to somehow figure out if the CoreFoundation library has already been loaded and avoid reloading it? Or maybe that is just not possible? If it's already been loaded, no problem. If it hasn't been loaded and PLplot loads the aquaterm driver, that will load CoreFoundation. This is probably not unique to the aquaterm driver. I think loading the xcairo driver also ends up loading CoreFoundation if it hasn't been loaded already, so that too would be subjected to this behavior. Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Move plgdev call to after plinit in example 14
Changes examples/*/x14*.* to call plgdev and print the driver name after calling plinit. Calling plgdev after plparseopts but before plinit will only get a device name if one is specified on the command line via the -dev option. If the device is not specified via -dev, calling plgdev before plinit will get an empty string. To ensure that plgdev gets a device name regardless of how it is specified, it must be called after plinit (specifically, after pllib_devinit, which is called by plinit). Without this change, running example 14 with no device specified on the command line would result in the following message... Demo of multiple output streams via the driver. Note the double space between the and driver where the driver name belongs. Also removes previously superfluous, now invalid call to plsdev before plinit. Tested C++, C, F77, and F95 versions. Not sure if other languages are modified correctly. --- examples/c++/x14.cc| 17 - examples/c/x14c.c | 17 - examples/d/x14d.d | 21 ++--- examples/f77/x14f.fm4 | 25 - examples/f95/x14f.f90 | 25 - examples/java/x14.java | 19 +-- examples/lua/x14.lua | 13 ++--- examples/ocaml/x14.ml | 15 +++ examples/octave/x14c.m | 25 - examples/perl/x14.pl | 15 +++ examples/tcl/x14.tcl | 13 ++--- 11 files changed, 97 insertions(+), 108 deletions(-) diff --git a/examples/c++/x14.cc b/examples/c++/x14.cc index 80569ad..54759c8 100644 --- a/examples/c++/x14.cc +++ b/examples/c++/x14.cc @@ -92,7 +92,7 @@ x14::x14( int argc, const char ** argv ) // Using DP results in a crash at the end due to some odd cleanup problems // The geometry strings MUST be in writable memory -char driver[80]; +char driver[80] = ; PLINT fam, num, bmax; @@ -110,13 +110,6 @@ x14::x14( int argc, const char ** argv ) // Parse and process command line arguments. pls1-parseopts( argc, argv, PL_PARSE_FULL ); -pls1-gdev( driver ); -pls1-gfam( fam, num, bmax ); - -cout Demo of multiple output streams via the -driver driver. endl; -cout Running with the second stream as slave to the first.\n endl; - //If valid geometry specified on command line, use it for both streams. pls1-gpage( xp0, yp0, xleng0, yleng0, xoff0, yoff0 ); valid_geometry = ( xleng0 0 yleng0 0 ); @@ -128,12 +121,18 @@ x14::x14( int argc, const char ** argv ) else pls1-setopt( geometry, geometry_master ); -pls1-sdev( driver ); pls1-ssub( 2, 2 ); // Initialize PLplot. pls1-init(); +pls1-gdev( driver ); +pls1-gfam( fam, num, bmax ); + +cout Demo of multiple output streams via the +driver driver. endl; +cout Running with the second stream as slave to the first.\n endl; + pls2 = new plstream(); if ( valid_geometry ) diff --git a/examples/c/x14c.c b/examples/c/x14c.c index 22e38ba..ace4aa4 100644 --- a/examples/c/x14c.c +++ b/examples/c/x14c.c @@ -58,7 +58,7 @@ main( int argc, const char *argv[] ) char geometry_master[] = 500x410+100+200; char geometry_slave[] = 500x410+650+200; -char driver[80]; +char driver[80] = ; PLINT fam, num, bmax; PLFLT xp0, yp0; @@ -70,13 +70,6 @@ main( int argc, const char *argv[] ) (void) plparseopts( argc, argv, PL_PARSE_FULL ); -plgdev( driver ); -plgfam( fam, num, bmax ); - -printf( Demo of multiple output streams via the %s driver.\n, driver ); -printf( Running with the second stream as slave to the first.\n ); -printf( \n ); - /* If valid geometry specified on command line, use it for both streams. */ plgpage( xp0, yp0, xleng0, yleng0, xoff0, yoff0 ); valid_geometry = ( xleng0 0 yleng0 0 ); @@ -88,10 +81,16 @@ main( int argc, const char *argv[] ) else plsetopt( geometry, geometry_master ); -plsdev( driver ); plssub( 2, 2 ); plinit(); +plgdev( driver ); +plgfam( fam, num, bmax ); + +printf( Demo of multiple output streams via the %s driver.\n, driver ); +printf( Running with the second stream as slave to the first.\n ); +printf( \n ); + /* Start next stream */ plsstrm( 1 ); diff --git a/examples/d/x14d.d b/examples/d/x14d.d index 41fe5bb..0782f90 100644 --- a/examples/d/x14d.d +++ b/examples/d/x14d.d @@ -51,15 +51,6 @@ int main( char[][] args ) /* Parse and process command line arguments */ plparseopts( args, PL_PARSE_FULL ); -string driver; -plgdev( driver ); - -PLINT fam, num, bmax; -plgfam( fam, num, bmax ); - -writefln( Demo of multiple output streams via the %s driver., driver ); -writefln( Running with the second stream as slave to the first.\n ); - /* If valid geometry specified on command line, use it for both
Re: [Plplot-devel] Another feature request (maybe)
On Feb 1, 2010, at 12:53 , David MacMahon wrote: I think I have accomplished the changes described in the thread quoted below. I still have some testing to do, but I'd appreciate any comments on my approach. Preliminary testing shows negligible (i.e. undetectable) effect on performance. Not to toot my own horn, but I thought I'd add some more comments about this. I think the ability to use arbitrary storage of user data has many benefits, including: 1. FORTRAN arrays need not be transposed before passing to C functions. 2. It allow for not only the arbitrary of arrangement of the data, but also for arbitrary types of data since each element is returned by a user-defined function which can cast each element as needed to type PLFLT. This provides a path towards supporting both single and double precision user data in the same library, as well as integer user data, half precision user data, etc. More generally, the user defined function can transform each point for plotting. For example, the user data could be complex, but user-defined operator functions could be used to treat the data as just the real component, just the imaginary component, magnitudes, or phases. Another potential use of transformation operator functions would be to facilitate log plots. And, of course, the user data need not even be stored; it could be computed (e.g. fractals). 3. Simplifying interfaces with other libraries. For example, the GSL library has its own two dimensional data type (i.e. matrix). It also supports views into existing matrices (i.e. submatrix) with various stride options. By providing a small set of GSL-aware operator functions, pointers to GSL matrices and even GSL matrix views could be passed directly to the PLplot functions that accept operator functions. IMHO, the benefits are compelling enough and the apparent performance hit negligible enough that it could be argued that providing similar behavior for 1D data would be worthwhile! Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another feature request (maybe)
I think I have accomplished the changes described in the thread quoted below. I still have some testing to do, but I'd appreciate any comments on my approach. Preliminary testing shows negligible (i.e. undetectable) effect on performance. Here is a summary of what I did (a patch is available if desired, but I'd prefer to hold off sending it out until my testing is completed)... Support arbitrary storage of 2D user data Adds support for arbitrary storage of 2D user data. This is very similar to the technique employed by some existing functions (e.g. plfcont and plfshade) that use evaluator functions to access 2D user data that is stored in an arbtrary format. The new approach extends the concept of a user-supplied (or predefined) evaluator function to a group of user-supplied (or predefined) operator functions. The operator functions provide for various operations on the arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan, and minmax. To facilitate the passing of an entire family of operator functions (via function pointers), a plf2ops_t structure is defined to contain a pointer to each type of operator function. Predefined operator functions are defined for several common 2D data storage techniques. Variables (of type plf2ops_t) containing function pointers for these operator functions are also defined. New variants of functions that accept 2D data are created. The new variants accept the 2D data as two parameters: a pointer to a plf2ops_t structure containing (pointers to) suitable operator functions and a PLPointer to the actual 2D data store. Existing functions that accept 2D data are modified to simply pass their parameters to the corresponding new variant of the function, along with a pointer to the suitable predefined plf2ops_t stucture of operator function pointers. The list of functions for which new variants are created is: c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc, c_plot3dcl, c_plsurf3d, and c_plsurf3dl, and c_plgriddata. The new variants are named the same as their corresponding existing function except that the c_ prefix is changed to plf (e.g. the new variant of c_plmesh is called plfmesh). Adds plfvect declaration to plplot.h and changes the names (and only the names) of some plfvect arguments to make them slightly clearer. In order to maintain backwards API compatibility, this function and the other existing functions that use evaluator functions are NOT changed to use the new operator functions. Thanks for any feedback, Dave On Jan 6, 2010, at 22:43 , David MacMahon wrote: On Jan 6, 2010, at 17:14 , Maurice LeBrun wrote: Some centuries ago I did endow the contourer with the function evaluator technique to deal with the issue of C vs Fortran vs whatever array storage. Worked out nicely IMO. Would've liked to upgrade all array- handling functions in like fashion but so far I think it's only been done for the plshadexx family. Thanks, Maurice, I see that now in plfcont and plfshade. I think that's just the kind of thing that would be great to have for every function that deals with 1-D data. I'm willing to try my hand at adapting some other functions to use this technique. As far as I can tell, the list of functions that could benefit from this are... c_plgriddata (*) c_plmesh (**) c_plmeshc (**) c_plot3d (**) c_plot3dc (**) c_plot3dcl c_plimagefr (***) c_plimage (***) c_plsurf3d () c_plsurf3dl c_plvect (*) (*) c_plgriddata might need both a getter and a setter version of this technique. (**) calls through to c_plot3dcl (***) might need a plf... version of plMinMax2dGrid () calls through to c_plsurf3dl (*) already has a plfvect in plvect.c, but not plplot.h! My plan would be to rename the existing functions from c_pl... to plf... (or c_plf...?) and create new versions of the old functions that call the plf variant with a particular choice for f2eval and f2eval_data (as the c_plcont comments say). The only downside to doing this, AFAICT, is that the current behavior of these functions will be somewhat slower since they will be getting data via the evaluator function and not directly from the z[nx][ny] array (at least for z arrays that don't need to be pre-un- transposed into that format). If anyone thinks that (or anything else about this idea) is a show- stopper, please let me know ASAP so I don't spend time implementing something that won't be incorporated. Thanks, Dave -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel
Re: [Plplot-devel] Another weird WITH_FREETYPE=OFF thing
Hi, Alan, On Jan 28, 2010, at 18:55 , Alan W. Irwin wrote: On 2010-01-28 16:47-0800 David MacMahon wrote: On Jan 28, 2010, at 5:06 , Alan W. Irwin wrote: On 2010-01-27 23:04-0800 David MacMahon wrote: Is it generally OK to send patches to plplot-devel [...] Yes. Sending patches to plplot-devel as a compressed attachment is the preferred method. Thanks. Do you know what the size limit is on attachments sent to the list? As plplot-devel mailing list administrator, I long ago decided to set no size limit because I was irritated at other lists that had anal- retentive limits that interfered with communications. Thanks for clarifying that and for facilitating open communications! I had encountered an attachment size limit earlier, but I went back and checked and found that is was for a message sent to plplot- general rather than plplot-devel. Therefore, as far as I am concerned, PLplot developers have plenty of scope via this list to attach anything they like that is on topic. As a courtesy to those with limited bandwidth it would probably be a good idea to compress large attachments Agreed. It's also a courtesy to those who have plenty of bandwidth, but small in-box quotas. (surely there is a git patch option to do that routinely?) That's what I thought, too, but I'm still looking for it! The -- attach option will make the actual diff output be an attachment (the commit message is still sent in the message body), but I have yet to find an easy way to have it compress the attachment. If anyone knows how to do this, please share! The flip side of this is your recent post of your complete error report to a website rather than to the list was being way too cautious about bandwidth since that compressed tarball was only 83K (!) in size. :-) I suppose it's better to err on the side of caution. :-) Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another weird WITH_FREETYPE=OFF thing
On Jan 28, 2010, at 5:06 , Alan W. Irwin wrote: On 2010-01-27 23:04-0800 David MacMahon wrote: Is it generally OK to send patches to plplot-devel [...] Yes. Sending patches to plplot-devel as a compressed attachment is the preferred method. Thanks. Do you know what the size limit is on attachments sent to the list? git makes it easy to send patches as attachments :-), but it doesn't seem to have an easy way to send patches as compressed attachments :- (. I'll probably end up sending small patches to the list uncompressed (easy), medium patches to the list compressed (not so easy), and large patches to an appropriate committer off-list and compressed (not so easy) unless the committer doesn't mind uncompressed patched (easy again). I hope this will not bother anyone. Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [PATCH] Fix command line parsing bug for Mac OS X
Mac OS X has a global version of argc and argv. The global argv is
passed by reference into main, but the global argc is passed by value.
When c_plparseopts deletes arguments, it reduces the caller's argc value
and NULL terminates the argv array to match. The global argc and argv
must also be kept consistent so that future users of them (e.g.
system libraries loaded later with a device driver) will not try to
dereference the NULL pointer at the end of the shortened argv array.
This patch adds cmake tests to detect whether the function to access the
global argc variable (_NSGetArgc()) and the header file declaring it
(crt_externs.h) are available. If so, macros will be defined in
config.h. It also modifies c_plparseopts to update the global argc
variable to match the shortened argv when the appropriate config.h
macros are defined.
---
cmake/modules/plplot.cmake |3 +++
config.h.cmake |6 ++
src/plargs.c | 19 +++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/cmake/modules/plplot.cmake b/cmake/modules/plplot.cmake
index 5f78262..91af7f4 100644
--- a/cmake/modules/plplot.cmake
+++ b/cmake/modules/plplot.cmake
@@ -38,6 +38,7 @@ endif(NOT DEFAULT_CMAP1_FILE)
option(USE_FILL_INTERSECTION_POLYGON use fill_intersection_polygon OFF)
# Need these modules to do subsequent checks.
+include(CheckIncludeFile)
include(CheckIncludeFiles)
include(CheckFunctionExists)
include(CheckSymbolExists)
@@ -189,6 +190,7 @@ endif(NOT STDC_HEADERS)
check_include_files(unistd.h PL_HAVE_UNISTD_H)
check_include_files(termios.h HAVE_TERMIOS_H)
check_include_files(stdint.h PL_HAVE_STDINT_H)
+check_include_file(crt_externs.h HAVE_CRT_EXTERNS_H)
# AC_HEADER_SYS_WAIT
include(TestForStandardHeaderwait)
@@ -244,6 +246,7 @@ check_function_exists(popen HAVE_POPEN)
check_function_exists(usleep PL_HAVE_USLEEP)
check_function_exists(mkstemp PL_HAVE_MKSTEMP)
check_function_exists(mkstemp PL_HAVE_UNLINK)
+check_function_exists(_NSGetArgc HAVE_NSGETARGC)
# Check for FP functions, including underscored version which
# are sometimes all that is available on windows
diff --git a/config.h.cmake b/config.h.cmake
index 6bc3c6f..b0365ac 100644
--- a/config.h.cmake
+++ b/config.h.cmake
@@ -124,6 +124,9 @@
/* Define if popen is available */
#cmakedefine HAVE_POPEN
+/* Define if _NSGetArgc is available */
+#cmakedefine HAVE_NSGETARGC
+
/* Define if pthreads is available */
#cmakedefine HAVE_PTHREAD
@@ -153,6 +156,9 @@
/* Define to 1 if you have the termios.h header file. */
#cmakedefine HAVE_TERMIOS_H 1
+/* Define to 1 if you have the crt_externs.h header file. */
+#cmakedefine HAVE_CRT_EXTERNS_H 1
+
/* Define to 1 if the function unlink is available */
#cmakedefine PL_HAVE_UNLINK 1
diff --git a/src/plargs.c b/src/plargs.c
index 39f64e6..6150824 100644
--- a/src/plargs.c
+++ b/src/plargs.c
@@ -98,6 +98,13 @@
#include plplotP.h
#include ctype.h
+#ifdef HAVE_CRT_EXTERNS_H
+/*
+ * This include file has the declaration for _NSGetArgc(). See below.
+ */
+#include crt_externs.h
+#endif
+
/* Support functions */
static int ParseOpt( int *, const char ***, int *, const char ***, PLOptionTable * );
@@ -926,7 +933,19 @@ c_plparseopts( int *p_argc, const char **argv, PLINT mode )
*argsave++ = *argv++;
if ( argsave argend )
+{
*argsave = NULL;
+#ifdef HAVE_NSGETARGC
+/*
+ * Modify the global argc variable to match the shortened argv.
+ * The global argc and argv must be kept consistent so that future
+ * users of them (e.g. libraries loaded later with a device driver)
+ * will not try to dereference the null pointer at the end of the
+ * shortened argv array.
+ */
+*_NSGetArgc() = *p_argc;
+#endif
+}
}
return status;
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another weird WITH_FREETYPE=OFF thing
On Jan 27, 2010, at 23:49 , Arjen Markus wrote: that is a remarkable piece of detective work. Thanks! you have digged up is a rahter nasty feature here. Agreed! I agree that option 3b looks the cleanest. It should not be too hard to implement it - the build system has several examples on how to check for specific functions. Something along the lines of TestSignalType.cmake for instance. I actually found what I needed in cmake/modules/plplot.cmake. I just need to check for a header file and a function so it was just a few extra lines there and in comfig.h.cmake! I'll be sending the patch for option 3b to this list shortly. Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another weird WITH_FREETYPE=OFF thing
Hi, everyone, Thanks for all your help and ideas. I think I have solved this mystery. The symptoms are very misleading and confusing, but the underlying cause turns out to be fairly easy to understand. The problem is actually related to command line parsing. It turns out that C programs on Mac OS X have access to global variables NXArgc and NXArgv. They are used by one of the system libraries (I think it's CoreFoundation, but I could be wrong) that eventually gets loaded when using the xcairo driver. If c_plparseopts is called without the PL_OPT_NODELETE option AND it deletes arguments *before* this library gets loaded/initialized, then the program crashes (presumably when the library accesses the modified contents of NXArgv using the unmodified value of NXArgc). If c_plparseopts is called with the PL_OPT_NODELETE option OR if it deletes no arguments, OR if it deletes arguments *after* this library gets loaded/initialized, then the program does not crash. Using WITH_FREETYPE=ON causes the freetype library to be linked in (via `pkg-config --libs plplotd`) to the executable (e.g. x01c), which results in the system library getting loaded/initialized *before* c_plparseopts is called. Using WITH_FREETYPE=OFF does not link the freetype library to the executable. In this case, the relevant system library does not get loaded/initialized until *after* c_plparseopts. If c_plparseopts deletes command line arguments, then the program will crash (presumably when the library accesses the modified contents of NXArgv using the unmodified value of NXArgc). This can be confirmed by noting that x01c -dev xcairo crashes while PLPLOT_DEV=xcairo x01c works using the exact same installation. Adding PL_OPT_NODELETE to x01c's call to c_plparseopts also prevents the crash since not deleting arguments maintains consistency between NXArgc and the contents of NXArgv. I can think of several ways of preventing this problem: 1. Always include CoreFoundation in linker flags on Macs. 2. Change c_plparseopts to not NULL terminate the modified argv array, but instead point the extra elements to an empty string. I've already tried this locally (a two line change) and it works, but it ends up with argv[argc] not being a null pointer which violates http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf (see section 5.1.2.2.1 item 2). 3a. Add code within #if define ( __APPLE __) blocks so that NXArgc can be modified to match the modified contents of NXArgv/argv. This might also an issue on NeXTSTEP, since I think that's where Apple picked up these variables (hence the NX prefix) 3b. Create a cmake test for NXArgc/NXArgv and define a HAVE_NXARGC macro that can be used instead of __APPLE__. I think 3b might be the cleanest option, but I'm open other possibilities (including any I've not listed). Opinions? Thanks again, Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another weird WITH_FREETYPE=OFF thing
On Jan 27, 2010, at 16:42 , David MacMahon wrote: 3a. Add code within #if define ( __APPLE __) blocks so that NXArgc can be modified to match the modified contents of NXArgv/argv. This might also an issue on NeXTSTEP, since I think that's where Apple picked up these variables (hence the NX prefix) 3b. Create a cmake test for NXArgc/NXArgv and define a HAVE_NXARGC macro that can be used instead of __APPLE__. I think 3b might be the cleanest option, but I'm open other possibilities (including any I've not listed). Opinions? FWIW, I've created and tested a patch for 3a. It turns out that directly accessing NXArgc from a library is not possible, but there is a function... int * _NSGetArgc() ...declared in /usr/include/crt_externs.h that can be used to get a pointer to the global argc. If anyone wants the patch, let me know. Is it generally OK to send patches to plplot-devel or should I send them to a different list or should I send them off-list to a committer or should I ...? If someone wants to try doing 3b, I think it would be great, but my cmake skills are not up to that task (yet). Thanks, Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] pkg-config issue
Hi, Alan (et al), On Jan 24, 2010, at 19:49 , Alan W. Irwin wrote: That file is part of the tarball. Look for it in qhull-2010.1/ src/. The CMake-based build system that comes with the tarball really sucks (static libraries only, no install). Werner (with some help from me) is putting together an improved version of that which we plan to donate to the qhull developers. I attach a modified qhull-2010.1/src/CMakeLists.txt that worked for me on Linux, and I encourage you to generalize it for your own needs and get back to us. Thanks. I found that using the old autotools build for qhull (only available via source code checkout; not in the release tarball) installed the header files where they are expected. I also tried the CMakeLists.txt you attached and that too put the header files where they need to be. The only difference I noticed was that the CMakeLists.txt installation installed the qhull executable as $prefix/bin/qhullcmd instead of $prefix/bin/qhull. Dave -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] pkg-config issue
Thanks, Alan, I confirm that your most recently attached CMakeLists.txt file does indeed correct the qhullcmd issue. Thanks again, Dave On Jan 25, 2010, at 10:30 , Alan W. Irwin wrote: I attach (for Dave, Werner, and anybody else who builds qhull) a CMakeLists.txt file that corrects the qhullcmd issue that Dave found in my previous CMakeLists.txt file. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Another weird WITH_FREETYPE=OFF thing
During my recent rebuild attempts, I had drivers in the installation tree that had the old driver numbering scheme (i.e. xcairo was 59, but now it's 100). At one point, the WITH_FREETYPE=OFF build failed due to a driver numbering mismatch between what test-drv-info found and what xcairo.rc had in it. I was able to solve it by moving the installed drivers out of the way, but it seems odd that the build process would find these. Here's the relevant line from the build process... cd /Users/davidm/local/src/plplot/tmp.without_freetype/drivers ./ test-drv-info cairo /Users/davidm/local/src/plplot/ tmp.without_freetype/drivers/test_dyndrivers_dir/cairo.rc So I changed to the drivers subdir of the WITH_FREETYPE=OFF build tree, ran the command under ktrace... $ ktrace ./test-drv-info cairo xcairo:Cairo X Windows Driver:1:cairo:100:xcairo pdfcairo:Cairo PDF Driver:0:cairo:101:pdfcairo pscairo:Cairo PS Driver:0:cairo:102:pscairo svgcairo:Cairo SVG Driver:0:cairo:103:svgcairo pngcairo:Cairo PNG Driver:0:cairo:104:pngcairo extcairo:Cairo External Context Driver:0:cairo:106:extcairo ...and then looked at the output using kdump to see where cairo.so was being loaded from... $ kdump | grep -C5 cairo.so 18319 test-drv-info RET chdir 0 18319 test-drv-info CALL open(0x501760,0,0x1b6) 18319 test-drv-info NAMI /Users/davidm/local/lib/plplot5.9.5/ driversd/cairo.la 18319 test-drv-info RET open -1 errno 2 No such file or directory 18319 test-drv-info CALL open(0xbfffe780,0,0) 18319 test-drv-info NAMI /Users/davidm/local/lib/cairo.so 18319 test-drv-info RET open -1 errno 2 No such file or directory 18319 test-drv-info CALL close(0x) 18319 test-drv-info RET close -1 errno 9 Bad file descriptor 18319 test-drv-info CALL open(0x501760,0,0) 18319 test-drv-info NAMI /Users/davidm/local/lib/plplot5.9.5/ driversd/cairo.so 18319 test-drv-info RET open 4 18319 test-drv-info CALL fstat(0x4,0xbfffe2a8) 18319 test-drv-info RET fstat 0 18319 test-drv-info CALL pread(0x4,0xbfffcea8,0x1000,0) 18319 test-drv-info GIO fd 4 read 4096 bytes This shows that it was for some reason loading cairo.so from the install area rather than from within the build tree! Repeating the same test in my WITH_FREETYPE=ON build directory gave a decidedly different (and better!) result... $ kdump | grep -C5 cairo.so 18307 test-drv-info RET chdir 0 18307 test-drv-info CALL open(0x501760,0,0x1b6) 18307 test-drv-info NAMI /Users/davidm/local/src/plplot/ tmp.with_freetype/drivers/cairo.la 18307 test-drv-info RET open -1 errno 2 No such file or directory 18307 test-drv-info CALL open(0xbfffe780,0,0) 18307 test-drv-info NAMI /Users/davidm/local/lib/cairo.so 18307 test-drv-info RET open -1 errno 2 No such file or directory 18307 test-drv-info CALL close(0x) 18307 test-drv-info RET close -1 errno 9 Bad file descriptor 18307 test-drv-info CALL open(0x501760,0,0) 18307 test-drv-info NAMI /Users/davidm/local/src/plplot/ tmp.with_freetype/drivers/cairo.so 18307 test-drv-info RET open 4 18307 test-drv-info CALL fstat(0x4,0xbfffe2a8) 18307 test-drv-info RET fstat 0 18307 test-drv-info CALL pread(0x4,0xbfffcea8,0x1000,0) 18307 test-drv-info GIO fd 4 read 4096 bytes ...which shows cairo.so being loaded from the build tree. More details about the two build environments can be found at... http://astro.berkeley.edu/~davidm/plplot-devel/freetype-on-off.tgz If any curious souls out there can figure this out I'd sure appreciate it. I'm happy that it works with WITH_FREETYPE=ON because that's what I prefer, but I'm also perplexed as to why the build behaves differently with WITH_FREETYPE=OFF. Thanks, Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another driver sequence number question
On Jan 25, 2010, at 16:01 , David MacMahon wrote: Line 1490 of drivers/cairo.c... Sorry, make that line 1497. Dave -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] pkg-config issue
Hi, PLplot developers, On Jan 19, 2010, at 21:34 , David MacMahon wrote: I am in the process of updating my MacPorts installation, but after that finishes I will (try to) recreate the above steps and capture all the output you've requested. After finishing my MacPorts update. I am no longer able to build PLplot due to a missing header file for qhull. The MacPorts update brought with it qhull version 2010.1. Previously I had qhull version 2003.1. According to the qhull web site (http://www.qhull.org/): A serious bug was found in Qhull 2003.1 . Please upgrade to 2010.1 or apply poly.c-qh_gethash.patch.. The problem is that the MacPorts installation of qhull 2010.1 does NOT install the qhull/qhull_a.h file. Instead, it installs just libqhull.h. I don't know if this is a bug in the MacPorts qhull portfile or if it is a bug in qhull's installation process in general. From what I can tell of qhull's installation process (now using cmake), it looks like libqhull.h is the only header file installed (and even that is only in the qhull git repo, not in the qhull-2010.1-src.tgz distribution tarball!). I tried to replace the occurrences of qhull/qhull_a.h with libqhull.h, but it seems that libqhull.h includes user.h, which is another qhull header that does not get installed. Has anyone successfully built PLplot using qhull 2010.1? Thanks, Dave -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] A comment style issue
Hi, Alan,
On Jan 21, 2010, at 22:39 , Alan W. Irwin wrote:
I certainly find the // comments convenient, but I recently ran
into a small annoyance on a project with a manually maintained
Makefile. I found that I needed to use the gcc compiler option...
-std=gnu99
...in order to be able to use // comments and some other basics
like usleep and getopt.
I just did a test of a // comment with gcc (without any special
options),
and it compiled fine. Could you try to confirm that for your version
of gcc as well?
Yes, it recognizes // comments fine with no -std option, but then it
gives a warning about round(). Using -std=c99 (as indicated by man
3 round) then gives a warning about usleep(). Using -std=gnu99 gets
it all to work. FWIW, this is with gcc 4.1.2 on CentOS 5.3.
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ cat foo.c
#include unistd.h
#include math.h
#ifndef NO_COMMENT
// Test usleep and round functions
#endif
double foo(double x)
{
usleep(1);
return round(x);
}
$ gcc -c -o /dev/null foo.c
foo.c: In function 'foo':
foo.c:8: warning: incompatible implicit declaration of built-in
function 'round'
$ gcc -std=c89 -c -o /dev/null foo.c
foo.c:5: error: expected identifier or '(' before '/' token
# ifndef out the // comment
$ gcc -std=c89 -DNO_COMMENTS -c -o /dev/null foo.c
(no complaints, but no // comments either)
$ gcc -std=c99 -c -o /dev/null foo.c
foo.c: In function 'foo':
foo.c:7: warning: implicit declaration of function 'usleep'
$ gcc -std=gnu99 -c -o /dev/null foo.c
(no complaints and with // comments!)
I should note that gcc 4.3.4 (on my Mac, installed via macports)
compiles the above foo.c without any -std options (and with the //
comments).
Like I said earlier, I think cmake should be able to handle any
compiler specific issues, so I don't think my whining about this
should dissuade you from changing to // comments.
Dave
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
