HI,
I think this can be done as simple as using these two commands, but I’ve not
tried it before.
git clone —mirror oldrepo
git push —mirror newreeo
Here’s a slightly longer set of command which does the same. [1]
Worse case we can wipe the repo and ask again and/or ask Infra to franker it
f
Should we enable the attachment before the new workflow settle? so the
traditional workflow can transfer from google group to here
immediately.
There is no reason to send patches to any of the Apache resources now.
They cannot be used there until the repositories are in place and we
have at l
Should we enable the attachment before the new workflow settle? so the
traditional workflow can transfer from google group to here
immediately.
Thanks
Xiang
On Wed, Dec 18, 2019 at 5:55 AM Justin Mclean wrote:
>
> Hi,
>
> Other project use in no particular order:
> - GitHub issues
> - JIRA
> - M
PPMC members have Apache email addresses. Mine is gn...@apache.org for
example. I stumbled across this account configuration utility:
https://id.apache.org/ You can use that to setup your forwarding
address (and your github name) . I see some PPMC people already know
this. There is informat
Sounds good to me 8-)
On 12/17/2019 5:36 PM, Justin Mclean wrote:
Hi,
So the discussion on legal discuss has died down [1] and the SGA has been
filled. My reading of that legal thread is that you now OK to transfer
everything across. Code not owned by the Nuttx project can be worked as needed
Hi,
So the discussion on legal discuss has died down [1] and the SGA has been
filled. My reading of that legal thread is that you now OK to transfer
everything across. Code not owned by the Nuttx project can be worked as needed
as everything is under a compatible license (BSD/MIT) and we have I
Hi,
Other project use in no particular order:
- GitHub issues
- JIRA
- Mailing list
- Github PRs
Some (most?) accept multiple ways of submitting patches.
Thanks,
Justin
Hi,
> It will be awhile before anything happens. I hold these domains and they are
> being used for other purposes as well. I believe that I am supposed hand
> over trademarks and the like when we graduate. That is the point of no
> return. Up until that point everything is reversible (but
Justin, can we send the attachment to dev@nuttx.apache.org?
You can but it increases the chance the email will be marked as spam.
I believe we can ask Infra to modify that.
How do other projects accept patches? If there is a more standard
way, we should consider that.
I find a lot of g
Justin, can we send the attachment to dev@nuttx.apache.org?
You can but it increases the chance the email will be marked as spam. I believe
we can ask Infra to modify that.
How do other projects accept patches? If there is a more standard way,
we should consider that.
Greg
Hi,
> That would be fine... However, my personal email linked to many accounts,
> services, etc. is gn...@nuttx.org.
I see that complicates things a little, but reduces the risk of a cyber
squatter getting the name.
> That would be a little awkward. In the future, as you say, perhaps... unle
When things are ready and stable, I will disable nutt.org and redirect that to
the Apache Confluence website. Just let me know when nuttx.org is no longer
needed. nuttx.com will also be be redirected. Will that be at
https://nuttx.incubator.apache.org/ like the status page or
https://nut
When things are ready and stable, I will disable nutt.org and redirect that to
the Apache Confluence website. Just let me know when nuttx.org is no longer
needed. nuttx.com will also be be redirected. Will that be at
https://nuttx.incubator.apache.org/ like the status page or
https://nut
> On Dec 17, 2019, at 12:21 PM, Justin Mclean wrote:
>
> Hi,
>
>> When things are ready and stable, I will disable nutt.org and redirect that
>> to the Apache Confluence website. Just let me know when nuttx.org is no
>> longer needed. nuttx.com will also be be redirected. Will that be at
Hi,
> Justin, can we send the attachment to dev@nuttx.apache.org?
You can but it increases the chance the email will be marked as spam. I believe
we can ask Infra to modify that.
Thanks,
Justin
Hi,
> When things are ready and stable, I will disable nutt.org and redirect that
> to the Apache Confluence website. Just let me know when nuttx.org is no
> longer needed. nuttx.com will also be be redirected. Will that be at
> https://nuttx.incubator.apache.org/ like the status page or
>
On Tue, Dec 17, 2019 at 11:40 AM Xiang Xiao wrote:
> It seems that I can't attach the file to dev@nuttx.apache.org:(.
> My attachment in previous email also lose:
> https://lists.apache.org/thread.html/9bc6f92e39b9d2f401e1554c0e3270d574067ff608d13df1c1c1b11e%40
>
> Justin, can we send the attachme
Great work. It looks great; and you made it look easy ;)
The bring-up was fast... but there were a few long nights I am sure.
When things are ready and stable, I will disable nutt.org and redirect
that to the Apache Confluence website. Just let me know when nuttx.org
is no longer needed.
Brennan,
Great work. It looks great; and you made it look easy ;)
Cheers,
-david
> On Dec 17, 2019, at 6:43 AM, Xiang Xiao wrote:
>
> The new wiki look great, thanks your hard work, Brennan!
>
> -Original Message-
> From: David Sidrane
> Sent: 2019年12月17日 17:53
> To: dev@nuttx.apa
It seems that I can't attach the file to dev@nuttx.apache.org:(.
My attachment in previous email also lose:
https://lists.apache.org/thread.html/9bc6f92e39b9d2f401e1554c0e3270d574067ff608d13df1c1c1b11e%40
Justin, can we send the attachment to dev@nuttx.apache.org?
On Wed, Dec 18, 2019 at 12:17 AM
If it is not too device specific, I can put it on a branch and we can
haggle through the details before merging it to master.
I think your original proposal for nx_updatedisplay() would be okay
if it were renamed and took three arguments like:
int nx_synch(NXWINDOW hwnd, int cmd, unsigned l
another patch fix warning: 'g_nullstring' defined but not used.
I don't see anything attached.
On 12/17/2019 10:10 AM, Gregory Nutt wrote:
So, I think the path here is that I'll tidy up what I've done and
then I'll submit it for comment and kickabout, and see where we go
from there.
If it is not too device specific, I can put it on a branch and we can
haggle through the details befo
another patch fix warning: 'g_nullstring' defined but not used.
Thanks
Xiang
So, I think the path here is that I'll tidy up what I've done and then
I'll submit it for comment and kickabout, and see where we go from there.
If it is not too device specific, I can put it on a branch and we can
haggle through the details before merging it to master.
Linux uses Xorg for graphics. So if this feature is supported in
Linux, then I think it would be through Xorg? The NX server is the
tiny, moral equivalent of the XServer.
This is interesting:
https://hackaday.com/2018/08/14/run-a-linux-terminal-on-cheap-e-ink-displays/
The interface is w
On 12/17/2019 9:03 AM, Dave Marples wrote:
How are other operating systems / graphics libraries handling this?
From what I've seen they mostly don't...you end up with a parallel
graphics subsystem built on top of an SPI. We can do better than that,
given that very little needs to be extende
How are other operating systems / graphics libraries handling this?
From what I've seen they mostly don't...you end up with a parallel
graphics subsystem built on top of an SPI. We can do better than that,
given that very little needs to be extended.
Regards
DAVE
it looks nice
great work
On Tue, Dec 17, 2019, 16:53 Xiang Xiao wrote:
> The new wiki look great, thanks your hard work, Brennan!
>
> -Original Message-
> From: David Sidrane
> Sent: 2019年12月17日 17:53
> To: dev@nuttx.apache.org
> Subject: RE: [nuttx] Wiki Backup
>
> Looking good! Thank
The new wiki look great, thanks your hard work, Brennan!
-Original Message-
From: David Sidrane
Sent: 2019年12月17日 17:53
To: dev@nuttx.apache.org
Subject: RE: [nuttx] Wiki Backup
Looking good! Thank you Brennan!
-Original Message-
From: Brennan Ashton [mailto:bash...@brennanasht
It means that some practical
details of the implementation of the display technology are 'leaking' up
into the graphics abstraction, but I don't really see a way to avoid it.
Only the application knows when it's permissible to take an extended
time to perform an update.
How are other operating
On 12/17/19, Gregory Nutt wrote:
> Thanks. I understand better now.
>
> This is very specific to this hardware.I don't think this should
> involve the graphics system in such a device-specific way since this is
> a hardware interfacing issue that has nothing to with graphics other
> than a gr
For easy hacks, I would suggest a minimal, trivial device driver that
just supports the the FBIO_UPDATE command (and any other command
unique to the hardware). This driver would have to lie in the
board-specific logic or else have an SPI interface passed to it during
initialization. Or may
Thanks. I understand better now.
This is very specific to this hardware. I don't think this should
involve the graphics system in such a device-specific way since this is
a hardware interfacing issue that has nothing to with graphics other
than a graphics device is involved. There are eas
On Tue, Dec 17, 2019 at 8:44 AM Dave Marples wrote:
> It means that some practical
> details of the implementation of the display technology are 'leaking' up
> into the graphics abstraction, but I don't really see a way to avoid it.
> Only the application knows when it's permissible to take an ex
Hi Greg,
Thanks for the replies. Comments embedded;
What is the interface to the ePaper device? Is it through a serial
interface? Or a framebuffer interface?
The interface is over SPI. It 'looks like' a normal lcd supported by
lcd_dev_s. The particular one I have is write-only, but read/wri
Hmm...going further, the only way I see to deal with this at the nxgl
layer above the lcd structure itself is to add a nx_redraw with
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but
that makes the nxgl layer device-aware...I don't see how it can't be
really, these thing
I don't really see any way to avoid this. Greg, any suggestions for a
better approach?
I would needed to understand how you are forming these displays, where
the display resides (in application memory), and how you are interfacing
from the "display" to hardware. I really don't have a clue
... I want to go the other way - when the application has decided that
a new display is 'stable', it requests for it to be put on the screen.
I don't understand what that means. Where is this new display?
I need to understand more before I could comment.
I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update
an ePaper display.
What is the interface to the ePaper device? Is it through a serial
interface? Or a
Hmm...going further, the only way I see to deal with this at the nxgl
layer above the lcd structure itself is to add a nx_redraw with
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but
that makes the nxgl layer device-aware...I don't see how it can't be
really, these things a
Hi Alan,
I'm no expert on this stuff either but as I understand things the
nx_callback/redraw, is for when nx requests that the client redraws a
portion of the screen (See 2.3.4.1 of the NX Graphics Subsystem manual).
I want to go the other way - when the application has decided that a new
di
Hi Dave,
On 12/17/19, Dave Marples wrote:
> Folks,
>
> I've implemented an ePaper driver under nxgl, but as some of you are
> probably aware there needs to be an explicit redraw request to update an
> ePaper display.
>
Other guy already used ePaper with NX Graphic libs, if I'm not wrong
it was P
Looking good! Thank you Brennan!
-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Tuesday, December 17, 2019 1:21 AM
To: dev@nuttx.apache.org
Subject: Re: [nuttx] Wiki Backup
Did another major round of updates. I removed a few pages that just linked
to doc
Folks,
I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update an
ePaper display.
I'm not quite sure how to do that under nxgl as normally it would be
driven automatically. It also takes a fair bit of time (~1
I wanted to confirm that all mentors have access to the incubator SVN. Justin
McLean clearly does. Could Junping Du and Mohammad Asif Siddiqui confirm that
they have Incubator SVN access?
Thanks,
-Flavio
[REQUIREMENTS- NuttX Workflow]
I am creating this thread to gather ONLY REQUIREMENTS. See [DISCUSS - NuttX
Workflow]
After the requirements are gathered in one place we can discuss the merits
and vote on them.
Did another major round of updates. I removed a few pages that just linked
to documentation pages that are already linked in the documentation
section. We need to figure out what to do with what is in the
documentation section.
For PDFs and the like we can just attach them to the Documentation pa
48 matches
Mail list logo
