GitHub projects on geometry translation

Schorsch,

I've got a spelling correction for RRadout/README.md. Would you mind
granting me "contributor" permissions? Or would you rather I just e-mail it
to you?

···

--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || [email protected]

On Thu, Mar 3, 2016 at 9:02 AM, Georg Mischler <[email protected]> wrote:

While at it, I created three seperate projects on GitHub:

1.
https://github.com/gmischler/Torad
Mostly for historical reasons, and to get the hang of the system.

2.
https://github.com/gmischler/Dxf2rad-Radout
Yes, the two share most of the codebase, and are now available with
a MIT license too. Version 1.1 can also create view files.
Binaries are available from my own site. If anyone wants to contribute
any other platforms, I'll be happy to publish them there as well.
In the case of dxf2rad, this would probably first be Darwin on various
types of hardware.
With Radout, someone with a more recent Autocad and some experience with
the SDK should be able to port it with little effort. I still need
to update the R15 download on my site to include the ACIS enabled version.

3.
https://github.com/gmischler/RRadout
Last but not least.
As already mentioned for this one, contributions welcome and necessary!

Any further related discussions should probably go to radiance-dev.

Have fun!
-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

For simple documentation typos, email is probably best, because those
most likely exist on the web site as well (after checking myself,
I just fixed several instances of "seperate", one of my favourites).

For code fixes, the standard Git method seems to be pull requests.

If you want to help extending and refactoring the program, I can
of course give you contributor status.

-schorsch

···

Am 2016-03-04 03:14, schrieb Randolph M. Fritz:

Schorsch,

I've got a spelling correction for RRadout/README.md. Would you mind
granting me "contributor" permissions? Or would you rather I just
e-mail it to you?

--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || [email protected]

On Thu, Mar 3, 2016 at 9:02 AM, Georg Mischler <[email protected]> > wrote:

While at it, I created three seperate projects on GitHub:

1.
https://github.com/gmischler/Torad [1]
Mostly for historical reasons, and to get the hang of the system.

2.
https://github.com/gmischler/Dxf2rad-Radout [2]
Yes, the two share most of the codebase, and are now available with
a MIT license too. Version 1.1 can also create view files.
Binaries are available from my own site. If anyone wants to
contribute
any other platforms, I'll be happy to publish them there as well.
In the case of dxf2rad, this would probably first be Darwin on
various
types of hardware.
With Radout, someone with a more recent Autocad and some experience
with
the SDK should be able to port it with little effort. I still need
to update the R15 download on my site to include the ACIS enabled
version.

3.
https://github.com/gmischler/RRadout [3]
Last but not least.
As already mentioned for this one, contributions welcome and
necessary!

Any further related discussions should probably go to radiance-dev.

Have fun!
-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch
com
+schorsch.com [4]+ -- lighting design tools --
http://www.schorsch.com/ [5]

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev [6]

Links:
------
[1] https://github.com/gmischler/Torad
[2] https://github.com/gmischler/Dxf2rad-Radout
[3] https://github.com/gmischler/RRadout
[4] http://schorsch.com
[5] http://www.schorsch.com/
[6] http://www.radiance-online.org/mailman/listinfo/radiance-dev

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

The errors in separate were exactly what I had in mind, so that's solved.

"For code fixes, the standard Git method seems to be pull requests." Well,
but eventually you have to push them. Or do you mean doing a "pull" on
GitHub itself?

I'd love to work on these things but, as usual, not enough time and, in
this case, no current Revit license; the thing is appallingly expensive.

···

--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || [email protected]

On Thu, Mar 3, 2016 at 11:48 PM, Georg Mischler <[email protected]> wrote:

For simple documentation typos, email is probably best, because those
most likely exist on the web site as well (after checking myself,
I just fixed several instances of "seperate", one of my favourites).

For code fixes, the standard Git method seems to be pull requests.

If you want to help extending and refactoring the program, I can
of course give you contributor status.

-schorsch

Am 2016-03-04 03:14, schrieb Randolph M. Fritz:

Schorsch,

I've got a spelling correction for RRadout/README.md. Would you mind
granting me "contributor" permissions? Or would you rather I just
e-mail it to you?

--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || [email protected]

On Thu, Mar 3, 2016 at 9:02 AM, Georg Mischler <[email protected]> >> wrote:

While at it, I created three seperate projects on GitHub:

1.
https://github.com/gmischler/Torad [1]
Mostly for historical reasons, and to get the hang of the system.

2.
https://github.com/gmischler/Dxf2rad-Radout [2]
Yes, the two share most of the codebase, and are now available with
a MIT license too. Version 1.1 can also create view files.
Binaries are available from my own site. If anyone wants to
contribute
any other platforms, I'll be happy to publish them there as well.
In the case of dxf2rad, this would probably first be Darwin on
various
types of hardware.
With Radout, someone with a more recent Autocad and some experience
with
the SDK should be able to port it with little effort. I still need
to update the R15 download on my site to include the ACIS enabled
version.

3.
https://github.com/gmischler/RRadout [3]
Last but not least.
As already mentioned for this one, contributions welcome and
necessary!

Any further related discussions should probably go to radiance-dev.

Have fun!
-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch
com
+schorsch.com [4]+ -- lighting design tools --
http://www.schorsch.com/ [5]

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev [6]

Links:
------
[1] https://github.com/gmischler/Torad
[2] https://github.com/gmischler/Dxf2rad-Radout
[3] https://github.com/gmischler/RRadout
[4] http://schorsch.com
[5] http://www.schorsch.com/
[6] http://www.radiance-online.org/mailman/listinfo/radiance-dev

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

"For code fixes, the standard Git method seems to be pull requests."
Well, but eventually you have to push them. Or do you mean doing a
"pull" on GitHub itself?

I'm still figuring this out myself. Here's my current understanding:

A "pull request" is a request to the maintainer to merge changes from a
branch or a fork into the trunk. Since anyone can easily fork a project,
this seems the easiest way to contribute smaller or occasional fixes.

Not to confuse with the normal "pull" and "push" commands.

I'd love to work on these things but, as usual, not enough time and,
in this case, no current Revit license; the thing is appallingly
expensive.

That seems to be a common problem. I'm hoping for people with access
at work or at school. It doesn't necessarily have to be a brand new
release though. I'm not sure when they introduced the "Custom Exporter"
API, but I think it was before Revit 2014.

-schorsch

···

Am 2016-03-04 22:09, schrieb Randolph M. Fritz:

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

That's exactly right. Pull requests leave a nice paper trail of who did
what, and who requested what, but only work within the sphere of Git.

Randolph, you could also just make a diff/patch of your changes on your
branch ('git diff > changes.patch') and send to Schorsch, which he can
apply manually ('git apply changes.patch'):

https://git-scm.com/docs/git-diff

https://git-scm.com/docs/git-apply

This method works across version control systems, and is what I do to get
my changes (managed on GitHub) to Greg (who's using CVS).

- Rob

···

On 3/4/16, 2:50 PM, "Georg Mischler" <[email protected]> wrote:

I'm still figuring this out myself. Here's my current understanding:

A "pull request" is a request to the maintainer to merge changes from a
branch or a fork into the trunk. Since anyone can easily fork a project,
this seems the easiest way to contribute smaller or occasional fixes.

So what’s the sequence? First I clone the repo, so I have my own copy, make some changes on my own copy, test them, commit them locally, decide to submit them, and then what do I do to upload them to you for consideration?

Rob, Schorsch seems already to have picked up the problems and fixed them, so no need to send a patch.

Randolph

···

On Mar 4, 2016, at 1:50 PM, Georg Mischler <[email protected]> wrote:

Am 2016-03-04 22:09, schrieb Randolph M. Fritz:

"For code fixes, the standard Git method seems to be pull requests."
Well, but eventually you have to push them. Or do you mean doing a
"pull" on GitHub itself?

I'm still figuring this out myself. Here's my current understanding:

A "pull request" is a request to the maintainer to merge changes from a
branch or a fork into the trunk. Since anyone can easily fork a project,
this seems the easiest way to contribute smaller or occasional fixes.

Git terminology may be confusing at times. This helped me quite a bit:
https://help.github.com/articles/github-glossary/

The typical situation is to create a "fork" first, which will give you
a copy of the project on GitHub. The fork will maintain its connection
to the original, so it can be merged back later.
In contrast, "cloning" means to pull something to your local system
for editing.

Once you have commited and pushed your changes to the fork, you can
then send a pull request to the original project.
Pull requests should really be called "merge requests".

Technically, the same effect could be had by creating a branch within
the original project. A fork has the advantage that the original author
doesn't get involved until changes have been made, hopefully tested,
and a pull request comes in about them. You can probably best think
of a fork as an "external branch".

Anything else we'll just have to experiment with, as soon as the
opportunity arrives.

-schorsch

···

Am 2016-03-05 02:42, schrieb Randolph Fritz:

On Mar 4, 2016, at 1:50 PM, Georg Mischler <[email protected]> >> wrote:

Am 2016-03-04 22:09, schrieb Randolph M. Fritz:

"For code fixes, the standard Git method seems to be pull requests."
Well, but eventually you have to push them. Or do you mean doing a
"pull" on GitHub itself?

I'm still figuring this out myself. Here's my current understanding:

A "pull request" is a request to the maintainer to merge changes from a
branch or a fork into the trunk. Since anyone can easily fork a project,
this seems the easiest way to contribute smaller or occasional fixes.

So what’s the sequence? First I clone the repo, so I have my own copy,
make some changes on my own copy, test them, commit them locally,
decide to submit them, and then what do I do to upload them to you for
consideration?

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Pronoun troubles: who is doing what to which where?

So is this correct:

   1. I first use the "fork" button to create my own copy of the repository
   on GitHub
   2. Then I use "git clone" on my own system, referencing my fork. This
   downloads the repository to my system
   3. Commit my changes on my system.
   4. Use "push" on my system to upload my changes to my fork of the
   project on GitHub
   5. Then use GitHub's "New Pull Request" button on your repository to
   submit a pull request to you, who will (if you like my changes) incorporate
   my changes in your repository.

Git documents (and perhaps this is true of most free open source
documentation) seem to be written by people who know git for people who
know git. This makes the lives of people who don't know git difficult.

Correct on all points.
Actually, I'm not absolutely certain on which project you'll have to press
"New Pull Request", but that will be easy to find out.

I've probably been guilty of your #6 myself...

-schorsch

···

Am 2016-03-05 20:26, schrieb Randolph M. Fritz:

Pronoun troubles: who is doing what to which where?

So is this correct:

  * I first use the "fork" button to create my own copy of the
repository on GitHub
  * Then I use "git clone" on my own system, referencing my fork. This
downloads the repository to my system
  * Commit my changes on my system.
  * Use "push" on my system to upload my changes to my fork of the
project on GitHub
  * Then use GitHub's "New Pull Request" button on your repository to
submit a pull request to you, who will (if you like my changes)
incorporate my changes in your repository.

Git documents (and perhaps this is true of most free open source
documentation) seem to be written by people who know git for people
who know git. This makes the lives of people who don't know git
difficult.

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Actually, I'm not absolutely certain on which project you'll have to press
"New Pull Request", but that will be easy to find out.

I’m pretty sure it’s on yours, since you’re the one who receives the pull request.

I've probably been guilty of your #6 myself…

:slight_smile:

Randolph

That is correct.

···

On 3/5/16, 1:12 PM, "Randolph Fritz" <[email protected]> wrote:

Actually, I'm not absolutely certain on which project you'll have to
press
"New Pull Request", but that will be easy to find out.

I¹m pretty sure it¹s on yours, since you¹re the one who receives the pull
request.

While at it, I created three seperate projects on GitHub:

1.


Mostly for historical reasons, and to get the hang of the system.

2.


Yes, the two share most of the codebase, and are now available with
a MIT license too. Version 1.1 can also create view files.
Binaries are available from my own site. If anyone wants to contribute
any other platforms, I'll be happy to publish them there as well.
In the case of dxf2rad, this would probably first be Darwin on various
types of hardware.
With Radout, someone with a more recent Autocad and some experience with
the SDK should be able to port it with little effort. I still need
to update the R15 download on my site to include the ACIS enabled version.

3.


Last but not least.
As already mentioned for this one, contributions welcome and necessary!

Any further related discussions should probably go to radiance-dev.

Have fun!
-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/