Changing offset on B1-R1-A

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Changing offset on B1-R1-A

Michael Hughes

I was trying to change the offset on my barometer with:

echo "159" > /1-wire/1F.C9D100000000/main/26.113A20000000/B1-R1-A/offset

this hung and when I tried looking at the B1-R1-A directory with a ls,
that hung also.  Now owfs seems to be hung itself.

I am running FreeBSD 9.3-RELEASE-p39 #4
I built owfs from the ports collection and it is owfs-3.1.p1
I built fuse kernel module from the ports collection.

--
Michael D Hughes                            Loghome living is the best!

[hidden email]

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Jan Kandziora
Am 05.09.2016 um 04:45 schrieb Michael Hughes:

>
> I was trying to change the offset on my barometer with:
>
> echo "159" > /1-wire/1F.C9D100000000/main/26.113A20000000/B1-R1-A/offset
>
> this hung and when I tried looking at the B1-R1-A directory with a ls,
> that hung also.  Now owfs seems to be hung itself.
>
> I am running FreeBSD 9.3-RELEASE-p39 #4
> I built owfs from the ports collection and it is owfs-3.1.p1
> I built fuse kernel module from the ports collection.
>
To debug this, don't use fuse but change your setup to owserver instead.
It's easy. First, kill the "owfs" process (and owserver and other ow
processes which may hog the host adapter.)

Then, start owserver with --debug switch and the right bus adapter
option. For example, when you use the DS9490 USB adaptor, use

# owserver --debug --usb

In another terminal, use the owshell tools to access owserver:

$ owwrite /1F.C9D100000000/main/26.113A20000000/B1-R1-A/offset 159

Look at the owserver log. Send us the log.

As you have a DS2409 based hub, you could try to connect the barometer
board directly to the host adapter. The DS2409 is sometimes icky.

Kind regards

        Jan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Michael Hughes
On Mon, 5 Sep 2016 21:03:36 +0200
Jan Kandziora <[hidden email]> wrote:

> Am 05.09.2016 um 04:45 schrieb Michael Hughes:
> >
> > I was trying to change the offset on my barometer with:
> >
> > echo "159"
> > > /1-wire/1F.C9D100000000/main/26.113A20000000/B1-R1-A/offset
> >
> > this hung and when I tried looking at the B1-R1-A directory with a
> > ls, that hung also.  Now owfs seems to be hung itself.
> >
> > I am running FreeBSD 9.3-RELEASE-p39 #4
> > I built owfs from the ports collection and it is owfs-3.1.p1
> > I built fuse kernel module from the ports collection.
> >  
> To debug this, don't use fuse but change your setup to owserver
> instead. It's easy. First, kill the "owfs" process (and owserver and
> other ow processes which may hog the host adapter.)
>
> Then, start owserver with --debug switch and the right bus adapter
> option. For example, when you use the DS9490 USB adaptor, use
>
> # owserver --debug --usb
>
> In another terminal, use the owshell tools to access owserver:
>
> $ owwrite /1F.C9D100000000/main/26.113A20000000/B1-R1-A/offset 159
>
> Look at the owserver log. Send us the log.
>
> As you have a DS2409 based hub, you could try to connect the barometer
> board directly to the host adapter. The DS2409 is sometimes icky.
>
> Kind regards
>
> Jan
>
Jan,
I have attached the output from the owserver --debug.  It looks to me
that it was able to set the offset.
--
Michael D Hughes                            Loghome living is the best!

[hidden email]

------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

debug.txt (19K) Download Attachment
attachment1 (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Jan Kandziora
Am 06.09.2016 um 00:17 schrieb Michael Hughes:
>
> Jan, I have attached the output from the owserver --debug.  It
> looks to me that it was able to set the offset.
>
Yes, it seems this way. That means the owlib functions work.

Do you have this special problem with the FUSE binding only with that
special node? Or others, too?

That said, I always disadvise using the FUSE binding, as it has
concurrency issues. Instead, owserver and owshell is the way to go.


Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Michael Hughes
On Tue, 6 Sep 2016 00:35:38 +0200
Jan Kandziora <[hidden email]> wrote:

> Am 06.09.2016 um 00:17 schrieb Michael Hughes:
> >
> > Jan, I have attached the output from the owserver --debug.  It
> > looks to me that it was able to set the offset.
> >  
> Yes, it seems this way. That means the owlib functions work.
>
> Do you have this special problem with the FUSE binding only with that
> special node? Or others, too?
>
> That said, I always disadvise using the FUSE binding, as it has
> concurrency issues. Instead, owserver and owshell is the way to go.
>
>
> Kind regards
>
> Jan
>
Jan,
Thanks for your help.  If I use owserver, do I need FUSE?

--
Michael D Hughes                            Loghome living is the best!

[hidden email]

------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

attachment0 (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Jan Kandziora
Am 07.09.2016 um 00:14 schrieb Michael Hughes:
>
> Jan, Thanks for your help.  If I use owserver, do I need FUSE?
>
No. Only the "owfs" binary needs FUSE.

Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Johan Ström-3
On 07/09/16 00:59, Jan Kandziora wrote:
> Am 07.09.2016 um 00:14 schrieb Michael Hughes:
>> Jan, Thanks for your help.  If I use owserver, do I need FUSE?
>>
> No. Only the "owfs" binary needs FUSE.
How did it go with the earlier discussed new homepage/wiki where we can
document these things?.. :) Seems every other day these questions pop up
on the list.

Johan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Changing offset on B1-R1-A

Jan Kandziora
Am 07.09.2016 um 07:15 schrieb Johan Ström:
> On 07/09/16 00:59, Jan Kandziora wrote:
>> Am 07.09.2016 um 00:14 schrieb Michael Hughes:
>>> Jan, Thanks for your help.  If I use owserver, do I need FUSE?
>>>
>> No. Only the "owfs" binary needs FUSE.
> How did it go with the earlier discussed new homepage/wiki where we can
> document these things?.. :) Seems every other day these questions pop up
> on the list.
>
I think the most important improvement in documentation would be if we
have it editable by more than one or two persons. That's why I suggested
to start a wiki for it. To keep it simple for people to join the
documentation team.

To setup a new website in place of the old one, we have to contact Mike
Kalist and Paul Alfille. They should give the okay first to use the
information from the current website as the base.

If we had to rewrite from scratch, that would be an awful lot of work.

Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

New site

Johan Ström-3
On 07/09/16 10:48, Jan Kandziora wrote:

> Am 07.09.2016 um 07:15 schrieb Johan Ström:
>> How did it go with the earlier discussed new homepage/wiki where we can
>> document these things?.. :) Seems every other day these questions pop up
>> on the list.
>>
> I think the most important improvement in documentation would be if we
> have it editable by more than one or two persons. That's why I suggested
> to start a wiki for it. To keep it simple for people to join the
> documentation team.
>
> To setup a new website in place of the old one, we have to contact Mike
> Kalist and Paul Alfille. They should give the okay first to use the
> information from the current website as the base.

Well, Paul *did* reply last time this was up, asking how he could help
in transition (https://sourceforge.net/p/owfs/mailman/message/35247513/)
So I guess we should figure out what we (the active community) think the
best solution would be, and
then work towards that.

First of all, today we have
* www.owfs.org (where is that hosted, and where is the source?)
* https://sourceforge.net/projects/owfs/ with GIT, basic descriptions,
tickets, releases & mailinglist.

There have been some suggestions for replacing the site so far, I'll try
to list some pros and cons, and personal thoughts.

# Migrate all info to a Wiki
MediaWiki was brought up as an example, however requires
hosting/security etc. The same applies for most other dynamic-style wikis.
Sourceforge has some kind of wiki functionality as well (actually, we
seem to have it.. https://sourceforge.net/p/owfs/wiki/Home/). Downside
with SF wiki is that it is embedded into SF site.

Pros:
  - multiple contributors easy, no need to learn git/coding to contribute
  - often WYSIWYG editor.
Possible cons:
  - we might need to handle another access setup, possibly separated
from GIT access. Could however be a good thing, to not permit git access
but permit docs contribution.
  - hosting? Good and flexible system?

# Setup static docs
Statically generate docs (somewhere) and push them to static hosting.
For examples, generate from some source, using Sphix, jekyll or similar.
Hosting can be done for example on pages.github.com, readthedocs.org. Or
hosted third party somewhere.

Pro:
- would be able to properly version it in git
- Could integrate with automatic build on push, using pull requests for
contribution etc.
- static is simple
Cons:
- Depending on how it's implemented, it could be trickier to contribute.
But most contributors are probably somewhat tech-savvy anyway..

---

I'm going to lift a followup question: should we stay on sourceforge?
Even if Github may be hyped and nowadays used by every granny and her
cat, it *is* a lot better than Sourceforge when it comes to git.. and
everything around it..
We would certainly not be the first project to leave SF.. They may not
yet have covertly bundled installers and what not with owfs, but who
knows..
(http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).

I haven't looked at github pages much more than during writing message,
but something like this is tempting:
* Move project to github: git hosting, issue handling, pull requests.
* Setup new github pages, automatically built by pushing to either main
repo or a separate site repo. If we juse sphinx,  jekyll, or plain
markdown, or something else, I don't know.
* Handle contributions to docs and source the same way: pull requests

Github could thus handle: GIT, basic descriptions, issues, pull
requests, pages (site), releases.
However, not mailinglist. We could keep that at sourceforge though.

(as it happens, I just created https://github.com/owfs. If we're not
going to use it, then at least so no-one else can steal it.. :))

> If we had to rewrite from scratch, that would be an awful lot of work.
That it would indeed.. But at the same time, we would need to go through
everything and clean out a lot of old/bad examples anyway. I'd say,
unless we're to keep the old site totally, we need to go through all
pages and move/filter the content.


Johan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

CReese
Github + wiki. I can help. I have content (all devices list, easy
explanation of owserver/owfs relationship, etc.) that I will gladly
contribute.

Colin


On 9/7/2016 12:23 PM, Johan Ström wrote:

> On 07/09/16 10:48, Jan Kandziora wrote:
>> Am 07.09.2016 um 07:15 schrieb Johan Ström:
>>> How did it go with the earlier discussed new homepage/wiki where we can
>>> document these things?.. :) Seems every other day these questions pop up
>>> on the list.
>>>
>> I think the most important improvement in documentation would be if we
>> have it editable by more than one or two persons. That's why I suggested
>> to start a wiki for it. To keep it simple for people to join the
>> documentation team.
>>
>> To setup a new website in place of the old one, we have to contact Mike
>> Kalist and Paul Alfille. They should give the okay first to use the
>> information from the current website as the base.
>
> Well, Paul *did* reply last time this was up, asking how he could help
> in transition (https://sourceforge.net/p/owfs/mailman/message/35247513/)
> So I guess we should figure out what we (the active community) think the
> best solution would be, and
> then work towards that.
>
> First of all, today we have
> * www.owfs.org (where is that hosted, and where is the source?)
> * https://sourceforge.net/projects/owfs/ with GIT, basic descriptions,
> tickets, releases & mailinglist.
>
> There have been some suggestions for replacing the site so far, I'll try
> to list some pros and cons, and personal thoughts.
>
> # Migrate all info to a Wiki
> MediaWiki was brought up as an example, however requires
> hosting/security etc. The same applies for most other dynamic-style wikis.
> Sourceforge has some kind of wiki functionality as well (actually, we
> seem to have it.. https://sourceforge.net/p/owfs/wiki/Home/). Downside
> with SF wiki is that it is embedded into SF site.
>
> Pros:
>   - multiple contributors easy, no need to learn git/coding to contribute
>   - often WYSIWYG editor.
> Possible cons:
>   - we might need to handle another access setup, possibly separated
> from GIT access. Could however be a good thing, to not permit git access
> but permit docs contribution.
>   - hosting? Good and flexible system?
>
> # Setup static docs
> Statically generate docs (somewhere) and push them to static hosting.
> For examples, generate from some source, using Sphix, jekyll or similar.
> Hosting can be done for example on pages.github.com, readthedocs.org. Or
> hosted third party somewhere.
>
> Pro:
> - would be able to properly version it in git
> - Could integrate with automatic build on push, using pull requests for
> contribution etc.
> - static is simple
> Cons:
> - Depending on how it's implemented, it could be trickier to contribute.
> But most contributors are probably somewhat tech-savvy anyway..
>
> ---
>
> I'm going to lift a followup question: should we stay on sourceforge?
> Even if Github may be hyped and nowadays used by every granny and her
> cat, it *is* a lot better than Sourceforge when it comes to git.. and
> everything around it..
> We would certainly not be the first project to leave SF.. They may not
> yet have covertly bundled installers and what not with owfs, but who
> knows..
> (http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).
>
> I haven't looked at github pages much more than during writing message,
> but something like this is tempting:
> * Move project to github: git hosting, issue handling, pull requests.
> * Setup new github pages, automatically built by pushing to either main
> repo or a separate site repo. If we juse sphinx,  jekyll, or plain
> markdown, or something else, I don't know.
> * Handle contributions to docs and source the same way: pull requests
>
> Github could thus handle: GIT, basic descriptions, issues, pull
> requests, pages (site), releases.
> However, not mailinglist. We could keep that at sourceforge though.
>
> (as it happens, I just created https://github.com/owfs. If we're not
> going to use it, then at least so no-one else can steal it.. :))
>
>> If we had to rewrite from scratch, that would be an awful lot of work.
> That it would indeed.. But at the same time, we would need to go through
> everything and clean out a lot of old/bad examples anyway. I'd say,
> unless we're to keep the old site totally, we need to go through all
> pages and move/filter the content.
>
>
> Johan
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Jan Kandziora
In reply to this post by Johan Ström-3
Am 07.09.2016 um 21:23 schrieb Johan Ström:

>
> Pro:
> - would be able to properly version it in git
> - Could integrate with automatic build on push, using pull requests for
> contribution etc.
> - static is simple
> Cons:
> - Depending on how it's implemented, it could be trickier to contribute.
> But most contributors are probably somewhat tech-savvy anyway..
>
If we use "simple" markup, we have to pick a person who extends the
"simple" markup as needed. I don't like the idea of not being able to
draw a table in a certain way or arrange text around an image just
because the "simple" markup does not support what I need.

In reality, we don't need this "simple" markup when all the people who
are contributing to the documentation are developers.

It's either user+developers, then cms/wiki is the way to go, or plain
old html files, with some preprocessing to put each article into a
common frame, suppling breadcrumbs and a table of contents
automatically. All inbetween will gives us a headache.


>
> I'm going to lift a followup question: should we stay on sourceforge?
> Even if Github may be hyped and nowadays used by every granny and her
> cat, it *is* a lot better than Sourceforge when it comes to git.. and
> everything around it..
> We would certainly not be the first project to leave SF.. They may not
> yet have covertly bundled installers and what not with owfs, but who
> knows..
> (http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).
>
I have some old projects at sourceforge but yes, I've started new
projects on github only since some years ago. I would never again begin
a new project on sf.net.

Why? Because sf.net is the yahoo of software. Totally bloated and full
of bells and whistles you don't want, with the main functions
complicated and brittle.



> I haven't looked at github pages much more than during writing message,
> but something like this is tempting:
> * Move project to github: git hosting, issue handling, pull requests.
> * Setup new github pages, automatically built by pushing to either main
> repo or a separate site repo. If we juse sphinx,  jekyll, or plain
> markdown, or something else, I don't know.
> * Handle contributions to docs and source the same way: pull requests
>
> Github could thus handle: GIT, basic descriptions, issues, pull
> requests, pages (site), releases.
> However, not mailinglist. We could keep that at sourceforge though.
>
I would like to consolidate the ways to report problems and bugs. It's a
bit tedious to have this at so many locations. Sourceforge does a
terrible job translating between the different interfaces.

Any good plan how to migrate this? What should the mailing list be good
for in the future? Developers only? If yes, who is taking care for
people reporting problems and bugs on the github tracker?


> (as it happens, I just created https://github.com/owfs. If we're not
> going to use it, then at least so no-one else can steal it.. :))
>
Fine. Please add me (ianka) to the organisation.


>> If we had to rewrite from scratch, that would be an awful lot of work.
> That it would indeed.. But at the same time, we would need to go through
> everything and clean out a lot of old/bad examples anyway. I'd say,
> unless we're to keep the old site totally, we need to go through all
> pages and move/filter the content.
>
This, yes. My concern was about authorship and copyright mostly.
"© Copyright 2003-2016 - OWFS website" isn't a good thing to start with.


Kind regards

        Jan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

CReese
What are the cons for a github-hosted wiki again?

It really seems to make sense to have all of the source and the how-to
hosted in one place, in an easy to use and modify format. Admin and
source control is easy to use (it is designed for it, after all),
managed, and attached to the repo for owfs itself. This really seems
like the obvious solution to me.

https://help.github.com/articles/about-github-wikis/

Colin


On 9/7/2016 3:03 PM, Jan Kandziora wrote:

> Am 07.09.2016 um 21:23 schrieb Johan Ström:
>>
>> Pro:
>> - would be able to properly version it in git
>> - Could integrate with automatic build on push, using pull requests for
>> contribution etc.
>> - static is simple
>> Cons:
>> - Depending on how it's implemented, it could be trickier to contribute.
>> But most contributors are probably somewhat tech-savvy anyway..
>>
> If we use "simple" markup, we have to pick a person who extends the
> "simple" markup as needed. I don't like the idea of not being able to
> draw a table in a certain way or arrange text around an image just
> because the "simple" markup does not support what I need.
>
> In reality, we don't need this "simple" markup when all the people who
> are contributing to the documentation are developers.
>
> It's either user+developers, then cms/wiki is the way to go, or plain
> old html files, with some preprocessing to put each article into a
> common frame, suppling breadcrumbs and a table of contents
> automatically. All inbetween will gives us a headache.
>
>
>>
>> I'm going to lift a followup question: should we stay on sourceforge?
>> Even if Github may be hyped and nowadays used by every granny and her
>> cat, it *is* a lot better than Sourceforge when it comes to git.. and
>> everything around it..
>> We would certainly not be the first project to leave SF.. They may not
>> yet have covertly bundled installers and what not with owfs, but who
>> knows..
>> (http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).
>>
> I have some old projects at sourceforge but yes, I've started new
> projects on github only since some years ago. I would never again begin
> a new project on sf.net.
>
> Why? Because sf.net is the yahoo of software. Totally bloated and full
> of bells and whistles you don't want, with the main functions
> complicated and brittle.
>
>
>
>> I haven't looked at github pages much more than during writing message,
>> but something like this is tempting:
>> * Move project to github: git hosting, issue handling, pull requests.
>> * Setup new github pages, automatically built by pushing to either main
>> repo or a separate site repo. If we juse sphinx,  jekyll, or plain
>> markdown, or something else, I don't know.
>> * Handle contributions to docs and source the same way: pull requests
>>
>> Github could thus handle: GIT, basic descriptions, issues, pull
>> requests, pages (site), releases.
>> However, not mailinglist. We could keep that at sourceforge though.
>>
> I would like to consolidate the ways to report problems and bugs. It's a
> bit tedious to have this at so many locations. Sourceforge does a
> terrible job translating between the different interfaces.
>
> Any good plan how to migrate this? What should the mailing list be good
> for in the future? Developers only? If yes, who is taking care for
> people reporting problems and bugs on the github tracker?
>
>
>> (as it happens, I just created https://github.com/owfs. If we're not
>> going to use it, then at least so no-one else can steal it.. :))
>>
> Fine. Please add me (ianka) to the organisation.
>
>
>>> If we had to rewrite from scratch, that would be an awful lot of work.
>> That it would indeed.. But at the same time, we would need to go through
>> everything and clean out a lot of old/bad examples anyway. I'd say,
>> unless we're to keep the old site totally, we need to go through all
>> pages and move/filter the content.
>>
> This, yes. My concern was about authorship and copyright mostly.
> "© Copyright 2003-2016 - OWFS website" isn't a good thing to start with.
>
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Johan Ström-3
On 08/09/16 00:13, Colin Reese wrote:
> What are the cons for a github-hosted wiki again?
Well, my only objection would be that it is a third party, but since
"we" don't really have a proper organization or funding or anything like
that which would naturally be able to "run it ourselfs", every solution
would become a third party in any way...
So, no, I don't have any cons for Github.
>
> It really seems to make sense to have all of the source and the how-to
> hosted in one place, in an easy to use and modify format. Admin and
> source control is easy to use (it is designed for it, after all),
> managed, and attached to the repo for owfs itself. This really seems
> like the obvious solution to me.
>
> https://help.github.com/articles/about-github-wikis/
It should be noted that Github wikis and Github pages are two different
things:

The Github wiki is inline in the repo UI, and features a basic WYSIWYG
editor (seems to support multiple markup methods). Either contributors
can edit, or all can edit, directly on site.
It doesn't seem easy to do vetting of edits though, i.e. "pull requests"
from contributors. Either you allow *everyone* to edit the wiki, or only
project collaborators (who can also commit code I guess?). It *is*
possible to manually handle the wiki as a git repo, and do merges that
way, but not via Github UI.

The Github pages are just static files commited to a GIT repo, which are
then presented standalone (no github UI) on xxx.github.io (custom domain
supported too).
For pages, you *can* use the built-in preprocessing framework Jekyll. I
tried it out a bit yesterday, you just commit static files the same way,
but you can create separate layout files and do some automatic
processing such as iterate files in a directory, or data structures etc,
and produce appropriate output. So, html/markdown/"jekyll code"/others
as input, html as output (which is shown on xxx.github.io).
Quite powerful, but requires some manual work. There is no web editor,
so you must clone the repo and edit it locally, making the threshold to
contribute a bit higher.

So both have pros and cons.. Regardless of which one we find most
suiting, I'd say we should keep all info in *one* place, and just use
the other for pointing to the first place. Don't have half of the info
in pages and wiki.. Or...? Perhaps basic info & best practices on Page,
and have non-collaborator contributions on wiki, where articles evolve
into best practices, which goes to the site?

>
> Colin
>
>
> On 9/7/2016 3:03 PM, Jan Kandziora wrote:
>> Am 07.09.2016 um 21:23 schrieb Johan Ström:
>>> Pro:
>>> - would be able to properly version it in git
>>> - Could integrate with automatic build on push, using pull requests for
>>> contribution etc.
>>> - static is simple
>>> Cons:
>>> - Depending on how it's implemented, it could be trickier to contribute.
>>> But most contributors are probably somewhat tech-savvy anyway..
>>>
>> If we use "simple" markup, we have to pick a person who extends the
>> "simple" markup as needed. I don't like the idea of not being able to
>> draw a table in a certain way or arrange text around an image just
>> because the "simple" markup does not support what I need.
It's nice to be flexible, but to what extent? Are there any formatting
languages supporting this, that is not manual HTML? I would not want to
do manual HTML for the overall content, just because we need special
tables in once place.
If we go with GH Wiki, their markdown seems to support inline HTML. If
we go with GH Pages, we can do whatever we want.
>>
>> In reality, we don't need this "simple" markup when all the people who
>> are contributing to the documentation are developers.
If I understand you correct, you want something more powerful, perhaps
HTML or other? If so, I don't agree. Its not about making it simple for
computer-illiterate people to contribute, it's making it easy for *us*
to write docs and not have to worry about writing verbose HTML around
everything to make it readable.
>>
>> It's either user+developers, then cms/wiki is the way to go, or plain
>> old html files, with some preprocessing to put each article into a
>> common frame, suppling breadcrumbs and a table of contents
>> automatically. All inbetween will gives us a headache.
In the later option, if we'd use the Github Pages Jekyll approach, its
easy to use HTML where needed and Markup (or some other supported
language) where needed.

>>
>>
>>> I'm going to lift a followup question: should we stay on sourceforge?
>>> Even if Github may be hyped and nowadays used by every granny and her
>>> cat, it *is* a lot better than Sourceforge when it comes to git.. and
>>> everything around it..
>>> We would certainly not be the first project to leave SF.. They may not
>>> yet have covertly bundled installers and what not with owfs, but who
>>> knows..
>>> (http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).
>>>
>> I have some old projects at sourceforge but yes, I've started new
>> projects on github only since some years ago. I would never again begin
>> a new project on sf.net.
>>
>> Why? Because sf.net is the yahoo of software. Totally bloated and full
>> of bells and whistles you don't want, with the main functions
>> complicated and brittle.
Good comparison... :)

>>
>>
>>
>>> I haven't looked at github pages much more than during writing message,
>>> but something like this is tempting:
>>> * Move project to github: git hosting, issue handling, pull requests.
>>> * Setup new github pages, automatically built by pushing to either main
>>> repo or a separate site repo. If we juse sphinx,  jekyll, or plain
>>> markdown, or something else, I don't know.
>>> * Handle contributions to docs and source the same way: pull requests
>>>
>>> Github could thus handle: GIT, basic descriptions, issues, pull
>>> requests, pages (site), releases.
>>> However, not mailinglist. We could keep that at sourceforge though.
>>>
>> I would like to consolidate the ways to report problems and bugs. It's a
>> bit tedious to have this at so many locations. Sourceforge does a
>> terrible job translating between the different interfaces.
>> Any good plan how to migrate this? What should the mailing list be good
>> for in the future? Developers only? If yes, who is taking care for
>> people reporting problems and bugs on the github tracker?
Good questions! Issues and pull requests should always be the problem &
bug-reporting location imo. This lists however has a lot of non-bug
questions too, more like support request around hardware. Should that
become GH issues? Not too sure.. One upside with mailing list is that it
reaches your inbox, if you are subscribed. With github you have to watch
the project to be notified of new issues etc..
I don't have an answer.. :)
>>
>>
>>> (as it happens, I just created https://github.com/owfs. If we're not
>>> going to use it, then at least so no-one else can steal it.. :))
>>>
>> Fine. Please add me (ianka) to the organisation.
Done

>>
>>
>>>> If we had to rewrite from scratch, that would be an awful lot of work.
>>> That it would indeed.. But at the same time, we would need to go through
>>> everything and clean out a lot of old/bad examples anyway. I'd say,
>>> unless we're to keep the old site totally, we need to go through all
>>> pages and move/filter the content.
>>>
>> This, yes. My concern was about authorship and copyright mostly.
>> "© Copyright 2003-2016 - OWFS website" isn't a good thing to start with.
Hm. Well that is ambiguous.. I've mailed with Colin off-list concerning
the contents origins. I'll see if I can find out the origins of the (C) too.

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Matthias Urlichs-3
On 08.09.2016 08:29, Johan Ström wrote:
Regardless of which one we find most
suiting, I'd say we should keep all info in *one* place
Personally I'd rather use Sphinx or similar. The main reason is that it's reasonably easy to sustain a coherent narrative structure, i.e. one could convert the whole thing to a single PDF for off-line perusal (or even (inclusion in) a book).

Also, you can store the API documentation within the code, so there's a chance it'll actually stay up to date.

I wouldn't even think of trying that with a Wiki-like approach.

-- 
-- Matthias Urlichs

------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

CReese
In reply to this post by Johan Ström-3
Here is an example of pages made using Sphinx:

https://pgm.readthedocs.io/en/develop/

C

> On Sep 7, 2016, at 11:29 PM, Johan Ström <[hidden email]> wrote:
>
>> On 08/09/16 00:13, Colin Reese wrote:
>> What are the cons for a github-hosted wiki again?
> Well, my only objection would be that it is a third party, but since
> "we" don't really have a proper organization or funding or anything like
> that which would naturally be able to "run it ourselfs", every solution
> would become a third party in any way...
> So, no, I don't have any cons for Github.
>>
>> It really seems to make sense to have all of the source and the how-to
>> hosted in one place, in an easy to use and modify format. Admin and
>> source control is easy to use (it is designed for it, after all),
>> managed, and attached to the repo for owfs itself. This really seems
>> like the obvious solution to me.
>>
>> https://help.github.com/articles/about-github-wikis/
> It should be noted that Github wikis and Github pages are two different
> things:
>
> The Github wiki is inline in the repo UI, and features a basic WYSIWYG
> editor (seems to support multiple markup methods). Either contributors
> can edit, or all can edit, directly on site.
> It doesn't seem easy to do vetting of edits though, i.e. "pull requests"
> from contributors. Either you allow *everyone* to edit the wiki, or only
> project collaborators (who can also commit code I guess?). It *is*
> possible to manually handle the wiki as a git repo, and do merges that
> way, but not via Github UI.
>
> The Github pages are just static files commited to a GIT repo, which are
> then presented standalone (no github UI) on xxx.github.io (custom domain
> supported too).
> For pages, you *can* use the built-in preprocessing framework Jekyll. I
> tried it out a bit yesterday, you just commit static files the same way,
> but you can create separate layout files and do some automatic
> processing such as iterate files in a directory, or data structures etc,
> and produce appropriate output. So, html/markdown/"jekyll code"/others
> as input, html as output (which is shown on xxx.github.io).
> Quite powerful, but requires some manual work. There is no web editor,
> so you must clone the repo and edit it locally, making the threshold to
> contribute a bit higher.
>
> So both have pros and cons.. Regardless of which one we find most
> suiting, I'd say we should keep all info in *one* place, and just use
> the other for pointing to the first place. Don't have half of the info
> in pages and wiki.. Or...? Perhaps basic info & best practices on Page,
> and have non-collaborator contributions on wiki, where articles evolve
> into best practices, which goes to the site?
>>
>> Colin
>>
>>
>>> On 9/7/2016 3:03 PM, Jan Kandziora wrote:
>>>> Am 07.09.2016 um 21:23 schrieb Johan Ström:
>>>> Pro:
>>>> - would be able to properly version it in git
>>>> - Could integrate with automatic build on push, using pull requests for
>>>> contribution etc.
>>>> - static is simple
>>>> Cons:
>>>> - Depending on how it's implemented, it could be trickier to contribute.
>>>> But most contributors are probably somewhat tech-savvy anyway..
>>> If we use "simple" markup, we have to pick a person who extends the
>>> "simple" markup as needed. I don't like the idea of not being able to
>>> draw a table in a certain way or arrange text around an image just
>>> because the "simple" markup does not support what I need.
> It's nice to be flexible, but to what extent? Are there any formatting
> languages supporting this, that is not manual HTML? I would not want to
> do manual HTML for the overall content, just because we need special
> tables in once place.
> If we go with GH Wiki, their markdown seems to support inline HTML. If
> we go with GH Pages, we can do whatever we want.
>>>
>>> In reality, we don't need this "simple" markup when all the people who
>>> are contributing to the documentation are developers.
> If I understand you correct, you want something more powerful, perhaps
> HTML or other? If so, I don't agree. Its not about making it simple for
> computer-illiterate people to contribute, it's making it easy for *us*
> to write docs and not have to worry about writing verbose HTML around
> everything to make it readable.
>>>
>>> It's either user+developers, then cms/wiki is the way to go, or plain
>>> old html files, with some preprocessing to put each article into a
>>> common frame, suppling breadcrumbs and a table of contents
>>> automatically. All inbetween will gives us a headache.
> In the later option, if we'd use the Github Pages Jekyll approach, its
> easy to use HTML where needed and Markup (or some other supported
> language) where needed.
>
>>>
>>>
>>>> I'm going to lift a followup question: should we stay on sourceforge?
>>>> Even if Github may be hyped and nowadays used by every granny and her
>>>> cat, it *is* a lot better than Sourceforge when it comes to git.. and
>>>> everything around it..
>>>> We would certainly not be the first project to leave SF.. They may not
>>>> yet have covertly bundled installers and what not with owfs, but who
>>>> knows..
>>>> (http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).
>>> I have some old projects at sourceforge but yes, I've started new
>>> projects on github only since some years ago. I would never again begin
>>> a new project on sf.net.
>>>
>>> Why? Because sf.net is the yahoo of software. Totally bloated and full
>>> of bells and whistles you don't want, with the main functions
>>> complicated and brittle.
> Good comparison... :)
>>>
>>>
>>>
>>>> I haven't looked at github pages much more than during writing message,
>>>> but something like this is tempting:
>>>> * Move project to github: git hosting, issue handling, pull requests.
>>>> * Setup new github pages, automatically built by pushing to either main
>>>> repo or a separate site repo. If we juse sphinx,  jekyll, or plain
>>>> markdown, or something else, I don't know.
>>>> * Handle contributions to docs and source the same way: pull requests
>>>>
>>>> Github could thus handle: GIT, basic descriptions, issues, pull
>>>> requests, pages (site), releases.
>>>> However, not mailinglist. We could keep that at sourceforge though.
>>> I would like to consolidate the ways to report problems and bugs. It's a
>>> bit tedious to have this at so many locations. Sourceforge does a
>>> terrible job translating between the different interfaces.
>>> Any good plan how to migrate this? What should the mailing list be good
>>> for in the future? Developers only? If yes, who is taking care for
>>> people reporting problems and bugs on the github tracker?
> Good questions! Issues and pull requests should always be the problem &
> bug-reporting location imo. This lists however has a lot of non-bug
> questions too, more like support request around hardware. Should that
> become GH issues? Not too sure.. One upside with mailing list is that it
> reaches your inbox, if you are subscribed. With github you have to watch
> the project to be notified of new issues etc..
> I don't have an answer.. :)
>>>
>>>
>>>> (as it happens, I just created https://github.com/owfs. If we're not
>>>> going to use it, then at least so no-one else can steal it.. :))
>>> Fine. Please add me (ianka) to the organisation.
> Done
>>>
>>>
>>>>> If we had to rewrite from scratch, that would be an awful lot of work.
>>>> That it would indeed.. But at the same time, we would need to go through
>>>> everything and clean out a lot of old/bad examples anyway. I'd say,
>>>> unless we're to keep the old site totally, we need to go through all
>>>> pages and move/filter the content.
>>> This, yes. My concern was about authorship and copyright mostly.
>>> "© Copyright 2003-2016 - OWFS website" isn't a good thing to start with.
> Hm. Well that is ambiguous.. I've mailed with Colin off-list concerning
> the contents origins. I'll see if I can find out the origins of the (C) too.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Jan Kandziora
In reply to this post by Matthias Urlichs-3
Am 08.09.2016 um 08:44 schrieb Matthias Urlichs:
> On 08.09.2016 08:29, Johan Ström wrote:
>> Regardless of which one we find most
>> suiting, I'd say we should keep all info in *one* place
> Personally I'd rather use Sphinx or similar. The main reason is that
> it's reasonably easy to sustain a coherent narrative structure, i.e. one
> could convert the whole thing to a single PDF for off-line perusal (or
> even (inclusion in) a book).
>
This is all very nice, very sleek, still someone has to persuade me to
write the documentation with this tool. Because I bet, in the long run,
no one else does. (No offense, anyone of the developers could have said
that.)

We need more collaborators for the documentation. A sleek output is
good, because people even value technical documentation by its looks.
But more important is a low barrier to contribute.


> Also, you can store the API documentation within the code, so there's a
> chance it'll actually stay up to date.
>
It came to me as experience my lifetime would never suffice to fix all
the things I know clever solutions for. So I usually stick to fix things
that are really a problem right now.

API documentation is off-track. We are talking about user documentation,
aren't we?

Kind regards

        Jan

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Colin Law
In reply to this post by Jan Kandziora
On 7 September 2016 at 23:03, Jan Kandziora <[hidden email]> wrote:
> ...
> In reality, we don't need this "simple" markup when all the people who
> are contributing to the documentation are developers.

Not necessarily true. I have recently been guided on this list as to
how to interface 1-wire devices to a Raspberry Pi and owserver.  I
would gladly add an application note to a wiki detailing how to do
this provided it was easy to do, so using something like Markup.

>
> It's either user+developers, then cms/wiki is the way to go, or plain
> old html files, with some preprocessing to put each article into a
> common frame, suppling breadcrumbs and a table of contents
> automatically. All inbetween will gives us a headache.

I am sure there are many developers who have would find it difficult,
or at least tedious, to write html.  Surely very few  do that
regularly nowadays.

Colin

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Jan Kandziora
Am 08.09.2016 um 09:58 schrieb Colin Law:

> On 7 September 2016 at 23:03, Jan Kandziora <[hidden email]> wrote:
>> ...
>> In reality, we don't need this "simple" markup when all the people who
>> are contributing to the documentation are developers.
>
> Not necessarily true. I have recently been guided on this list as to
> how to interface 1-wire devices to a Raspberry Pi and owserver.  I
> would gladly add an application note to a wiki detailing how to do
> this provided it was easy to do, so using something like Markup.
>
Stop. I'm not arguing against simple markus. I'm arguing against simple
markup if the only people who use this are developers.

Face it, simple markup alone will not give you any contributors. Hell,
non-developer documentation contributors don't want to bother with
markup at all!

What we need is an interface that makes it easy for *anyone* to
contribute to the documentation. If we don't have that, we could just
stick to HTML.


>
> I am sure there are many developers who have would find it difficult,
> or at least tedious, to write html.  Surely very few  do that
> regularly nowadays.
>
Really? I'm that old-school? Can't be.

Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Colin Law
On 8 September 2016 at 09:20, Jan Kandziora <[hidden email]> wrote:

> Am 08.09.2016 um 09:58 schrieb Colin Law:
>> On 7 September 2016 at 23:03, Jan Kandziora <[hidden email]> wrote:
>>> ...
>>> In reality, we don't need this "simple" markup when all the people who
>>> are contributing to the documentation are developers.
>>
>> Not necessarily true. I have recently been guided on this list as to
>> how to interface 1-wire devices to a Raspberry Pi and owserver.  I
>> would gladly add an application note to a wiki detailing how to do
>> this provided it was easy to do, so using something like Markup.
>>
> Stop. I'm not arguing against simple markup. I'm arguing against simple
> markup if the only people who use this are developers.

Stop what?  My "not necessarily" was about your suggestion that all
contributors would be developers.  Perhaps I misunderstand and you
meant "if all the people..." rather than "when all the people".
Whatever, I was just pointing out that I am not a developer and would
like to contribute.  However I am not arguing for Markup specifically,
just something simple.

>
> Face it, simple markup alone will not give you any contributors. Hell,
> non-developer documentation contributors don't want to bother with
> markup at all!

Wikipedia doesn't seem to have problems getting contributors.

>
> What we need is an interface that makes it easy for *anyone* to
> contribute to the documentation. If we don't have that, we could just
> stick to HTML.

Agree with first sentence.  Don't know about second.

One final point, the important thing is that the information is there
and accessible, how pretty it looks is of little importance.

>
>>
>> I am sure there are many developers who have would find it difficult,
>> or at least tedious, to write html.  Surely very few  do that
>> regularly nowadays.
>>
> Really? I'm that old-school? Can't be.

Fraid so :)

Colin

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: New site

Stefano Miccoli
In reply to this post by Jan Kandziora

On 08 Sep 2016, at 10:20, Jan Kandziora <[hidden email]> wrote:

Face it, simple markup alone will not give you any contributors. Hell,
non-developer documentation contributors don't want to bother with
markup at all!

What we need is an interface that makes it easy for *anyone* to
contribute to the documentation. If we don't have that, we could just
stick to HTML.

Sorry, but I **strongly** disagree: html if you don’t use some form of template engine is not sustainable.

Suppose you have 200+ pages, and you need to add a single row in the footer: should you open all the 200 html files by hand and add the html markup? Should you write a bash+sed+m4 script and programmatically change all the files? Or should you just change a single line in a template file and have some processor regenerate the whole site?

The real question here is not about having hundreds of contributors hacking docs with an WYSIWYG on-line editor. Our problem is to use a technology which allows us tho **efficiently** build a decent new owfs.org site.

My personal list of important requirements. The new site should be

1) static and integrated with git (push to publish)
2) future proof (ability to integrate new web technologies as they appear)
3) based on templates
4) allow for easy inclusion of html and css
5) be very lightweight as what regards maintenance.

You guessed it, I wrote the above list with jekyll in mind :-))

I use both jekyll and Sphinx: while Sphinx is the way to go for python or C docs (http://pyownet.readthedocs.io/en/latest/) it is not flexible enough for owfs.org, which should be a little more than a bunch of docs.

So consider jekyll https://jekyllrb.com as a system based on

* Markdown: a lightweight markup language, which is much more than *simple* markup. 
* Liquid, which is a template engine
* plain old html and css (you are not forced to use markdown or templates… a jekyll site could also be 100% html+css)

As a bonus with jekyll you get seamless integration into github (but NO vendor lock-in since it is fully open source), free hosting on pages.guthub.com, rouge syntax highlighting…

Stefano

------------------------------------------------------------------------------

_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
1234