[x3d-public] SourceForge -> GitHub (Was: Re: Possible extensions to x3d.py (subclassing, etc))
John Carlson
yottzumm at gmail.com
Tue Oct 31 18:13:00 PDT 2023
It sounds like we should start fresh, yet archive what’s on sourceforge.
I can start with XML schema and whatever is required for X3DUOM and
x3d.py. I personally am also interested in X3DJSAIL and X3dTo*.xslt.
(Mainly Java, Python and ECMAScript)
Maybe we should collect what people are interested in going forward into
the Metaverse.
I’m not interested in maintaining any webpages models, or doing releases.
I can read email and code, otherwise I am disabled. Sometimes, i need to
defer tasks to more capable people.
I’m sure the standards are already on GitHub, and will be maintained
separately, as they are now.
I’m guessing NPS is focused on maintaining X3D-Edit.
If people have a plan or structure for moving stuff into the
Web3DConsortium GitHub, let us know; I don’t have access that I know of.
I will start with a top-level repo x3d-code/
www.web3d.org/{x3d/stylesheets,specifications}, and take input from others
for other folders they want transferred. I don’t plan on incorporating
large files since I don’t “get” git-lfs.
Obviously, this is a starting point for discussion.
John
On Tue, Oct 31, 2023 at 7:15 PM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:
> Answering to """Michalis, are you still willing to do a transfer from
> sourceforge to GitHub? I’m not familiar with that.""" from John:
>
> I indeed pondered about migrating SVN repo on SourceForge (
> https://sourceforge.net/projects/x3d/ ) to GIT repo on GitHub. Using
> https://github.com/michaliskambi/sync2git , I did this conversion for
> a number of repos (including Castle Game Engine long long time ago).
> Such conversion can preserve the history (logs, blames) perfectly
> (using git-svn underneath). Initial attempts showed that old commits
> in SourceForge SVN repository are corrupted, so it's not a totally
> straightforward job, one will have to avoid problematic SVN revision
> ranges.
>
> I do not plan to do this anymore -- I lately suffer from terrible lack
> of time for anything, too many projects and too many tasks :)
>
> If someone else wants to do this job, go ahead. Note that you can
> first migrate to any GitHub repo, and later Don can decide whether to
> e.g. put it in https://github.com/Web3DConsortium/ organization (which
> I would recommend, but that's Don decision).
>
> Regards,
> Michalis
>
> śr., 1 lis 2023 o 00:22 John Carlson <yottzumm at gmail.com> napisał(a):
> >
> > Michalis, are you still willing to do a transfer from sourceforge to
> GitHub? I’m not familiar with that.
> >
> > Don, I have copied over my x3d.py versions. I really can’t go backwards
> every time you want me to. I make stupid mistakes copying files around and
> I have so many versions of the x3d.py stylesheet, I don’t know which is
> which.
> >
> > But there are plenty of Python examples in the archive which could be
> modified to output XML and the XML could be validated with tovrmlx3d. I
> have already show output from validating the output of a modified
> JoeKick.py. That is a is a great place to start, if JoeKick.py has not
> been replaced already.
> >
> > If you want a different X3dToPython.xslt to enable this, I have one.
> >
> > No one wants to run Python that hasn’t been thoroughly inspected.
> Obviously, I run a risk if I do so. I have also not inspected all of
> x3d.py to my satisfaction.
> >
> > I recommend running the python in a properly secured sandbox, possibly
> some kind of virtual machine, Kubernetes or Docker container. People in
> your position are more likely to have access and experience with this sort
> of thing, and have colleagues, students or former students that can help.
> I stepped out of that environment in 2012, basically live in the middle of
> corn fields, so I have little experience and contacts. Hint: none of my
> former colleagues want to discuss such things because I worked at a top
> secret weapons laboratory—plus they would rather be retired that deal with
> tech.
> >
> > You have the golden stylesheet and the golden x3d.py. I don’t want to
> flip to yours, because that would be backpedaling for me and possibly cause
> me a lot of confusion. I’m just trying to catch everybody up to where I
> am. What i could do is create a separate repository for x3d.py et al, so
> people could fork, branch, etc. on GitHub. This would require XML schema,
> X3DUOM, etc. etc.—too much. I’m only one guy. I can add collaborators,
> organizations, etc, but I’ve limited my GitHub experience on purpose. I
> don’t want to become the Python, XML or XSLT star when I dislike them. I’m
> the John for Java* guy, with experience with Perl. I use Python, because I
> don’t like DOM in JavaScript for pulling information out of XML, seems
> stunted, or I am unfamiliar with how to do it. I do know querySelector,
> maybe I should work on reading X3DUOM with that?
> >
> > If there’s a more recent version of x3d.py than 4.0.64.4 (?) that would
> be useful information.
> >
> > In other words, if I were to test my version of x3d.py the only issues
> that would show up would be containerField issues, I’m fairly sure. I can
> report on those. These are not visible in Python code, and Vince and
> Andreas already are on track with that. I will chime in after the holiday.
> >
> > Any subclasses of x3d.py would override the order of output in the XML,
> VRML and JSON output. They would not be generated from X3DUOM. I have no
> clue how to introduce custom field ordering in X3DUOM, and I would prefer
> to to it in the x3d.py stylesheet, but it’s mind-bending. With some better
> documentation about xsl:sort sequences, I might get somewhere, but I might
> step on some other node’s ordering, so a full test suite is required, which
> I’m willing to work on, but I need advice on how you capture ant output for
> ant/python as you do.
> >
> > If there aren’t issues with how others expect fields to be ordered in
> x3d.py, can we proceed?
> >
> >
> > John
> >
> > On Tue, Oct 31, 2023 at 4:27 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
> >>
> >> John, you are free to experimentally subclass or inject as you wish but
> there is no guarantee that such work will be maintainable.
> >>
> >>
> >>
> >> The way to upgrade x3d.py is to
> >>
> >>
> >>
> >> Show an erroneous output, or
> >> Provide example code showing a broadly useful utility method of some
> sort.
> >>
> >>
> >>
> >> Such corrections and improvements can then get autogenerated from
> X3DUOM into x3d.py and then regression tested against X3D Examples. If
> successfully working they can become part of a future x3d.py release, which
> is entirely open source.
> >>
> >>
> >>
> >> Python package x3d
> >> https://pypi.org/project/x3d
> >>
> >>
> >> Thanks in advance for all improvements to X3D and x3d.py python library.
> >>
> >>
> >>
> >> all the best, Don
> >>
> >> --
> >>
> >> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> >>
> >> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> >>
> >> X3D graphics, virtual worlds, navy robotics
> https://faculty.nps.edu/brutzman
> >>
> >>
> >>
> >> From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of John
> Carlson
> >> Sent: Tuesday, October 31, 2023 1:53 PM
> >> To: GPU Group <gpugroup at gmail.com>; Joe D Williams <
> joedwil at earthlink.net>
> >> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> Subject: [x3d-public] Possible extensions to x3d.py (subclassing, etc)
> >>
> >>
> >>
> >> I’m going to take the approach that x3d.py cannot be modified, and
> instead use subclasses of x3d.py classes to provide order of fields as
> necessary for the Blender X3DV exporter. In particular, HAnimHumanoid XML,
> VRML and JSON methods will be overridden to provide containerField, field
> ordering, etc.
> >>
> >>
> >>
> >> x3d.py might take a dependency injection approach in the future, such
> that one or more delegates can be replaced. I believe dependency injection
> is preferred to inheritance or monkey-patching, but X3D is pretty heavy
> into inheritance, or at least interfaces. Any dependency injection should
> make any changes to output as desired. I do not agree with totally
> replacing methods, as that is a maintenance nightmare.
> >>
> >>
> >>
> >> I apologize for all the emails over the last many days. My mind is not
> as nimble as it could be. I do not know if I could have arrived at a
> agreeable solution without all the emails.
> >>
> >>
> >>
> >> Now you know why technical interviews terrify me.
> >>
> >>
> >>
> >> Thanks everyone for being teddy bears.
> >>
> >>
> >>
> >> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231031/498303e4/attachment.html>
More information about the x3d-public
mailing list