phdl-devel — PHDL General Development Discussion

[phdl-devel] RR diagrams + semantics => compiler

[peter d. <hd...@ho...>]

Brent, Thanks for the link to the RR diagrams.  They actually answer a lot of questions.

Wes, Thanks for the discussion of semantics.  

I think the original project plan defined a formal language specification to be the first milestone.  It is normal and healthy to iterate like this.  A formal language spec is money in the bank and a the natural starting point for alternate implementations.

I think we may want to start a second implementation of the compiler to simplify maintenance and deployment.  That is what spurred me to look for the RR diagrams and BNF descriptions.  I realize the compiler is much more than the syntax but the input to any parser generator is a formal syntax.

Unfortunately, it is not obvious to me what a simplified implementation should be.

With what we have learned so far, what would be the best approach to building a PHDL compiler?

  Pete

From: bre...@by...
To: hd...@ho...
CC: phd...@li...
Subject: Re: [phdl-devel] BNF or railroad diagrams?
Date: Sat, 20 Oct 2012 21:06:04 +0000






There us a set of RR diagrams for 2.1 in the docs tab of the old web page.  It was auto generated. 



We (actually Josh) have been working on a BNF this week. Will be mailing on Monday or so to the group. 



The key is that, as Wes wisely said, we want a formal spec rather than just "what the current implementation does". 



Look for something in the next few days...  It is a BNF that he has been creating, by the way...



Brent




On Oct 20, 2012, at 2:25 PM, "Peter Dudley" <hd...@ho...> wrote:






BNF or railroad diagrams?

Guys,
I remember in one of the telecom it was mentioned that graphical railroad diagrams are generated in the compile process.   Equally good would be
Backus-Naur Form grammar descriptions.
Does anyone know where to find the BNF or railroad diagrams for PHDL 2.1? 


     Pete Dudley
     
hd...@ho...
     
www.HDLGuy.com


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

Everyone hates slow websites. So do we.

Make your web apps faster with AppDynamics

Download AppDynamics Lite for free today:

http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________

phdl-devel mailing list

phd...@li...

https://lists.sourceforge.net/lists/listinfo/phdl-devel

 		 	   		  

Re: [phdl-devel] BNF or railroad diagrams?

[Wesley J. L. <wj...@ic...>]

On Saturday, October 20, 2012 14:24:15 Peter Dudley wrote:
> Guys,
> I remember in one of the telecom it was mentioned that graphical railroad
> diagrams are generated in the compile process.   Equally good would be
> Backus-Naur Form grammar descriptions.
> 
> Does anyone know where to find the BNF or railroad diagrams for PHDL 2.1?

On Saturday, October 20, 2012 15:06:04 Brent Nelson wrote:
> There us a set of RR diagrams for 2.1 in the docs tab of the old web
> page.  It was auto generated.
> 
> We (actually Josh) have been working on a BNF this week. Will be mailing
> on Monday or so to the group.
> 
> The key is that, as Wes wisely said, we want a formal spec rather than
> just "what the current implementation does".
> 
> Look for something in the next few days...  It is a BNF that he has been
> creating, by the way...

This is good progress towards the goal of formally defining the language. 
I'm excited that we're making progress. I think we're going to be really 
happy that we've done it once we put a little effort into getting there.

(Below is possibly TL;DR material)

For the benefit of anyone wondering about the differences between defining 
the grammar and having a formal spec, the basic issue is the natural split 
between the language grammar itself, and what a program interprets that 
grammar to actually *mean* semantically.

RR diagrams, BNF, PEG, etc, are all different kinds of formalisms to clearly 
document a grammar. In theory you could just describe it in plain prose, but 
that tends to be error prone and ambiguous. BNF (traditionally) or PEG (more 
recently) are the de-facto standard ways to document modern language 
grammars. So getting in a form like that is a definte huge first step!

After we have the grammar, which tells us exactly what syntactic forms are 
correct for PHDL or not, we also need to define what the semantics of the 
grammar are. This is where a lot of good stuff come into play like not just 
saying it's legal to write "gnd = <gnd>" in a port assignment, but saying 
exactly what that does in that context. For instance, we all know that this 
assigns the single bit net called "gnd" in the current design level to each 
bit of the possibly multibit port called "gnd" on the device we are 
instantiating. Or for another example, writing "some_3_bit_net = 
some_8_bit_net" is legal in the grammar, but is illegal in the semantics of 
the language.

BTW, just like how grammars have special formal languages to describe them 
(BNF, PEG, etc) there are also several special formal languages that can 
used to describe semantics (such as denotational semantics formalisms, etc). 
In the case of PHDL, however, I think we're probably be better off to go 
with plain textual descriptions for the bulk of our descriptions, since 
otherwise I think we'll get wrapped around the axle trying to formalize 
mathematical models of things that can be explained simpler with words. But 
in small doses, specifying exactly what a language feature does with no 
ambiguity can be worth a little formality.

Re: [phdl-devel] BNF or railroad diagrams?

[Brent N. <bre...@by...>]

There us a set of RR diagrams for 2.1 in the docs tab of the old web page.  It was auto generated.

We (actually Josh) have been working on a BNF this week. Will be mailing on Monday or so to the group.

The key is that, as Wes wisely said, we want a formal spec rather than just "what the current implementation does".

Look for something in the next few days...  It is a BNF that he has been creating, by the way...

Brent


On Oct 20, 2012, at 2:25 PM, "Peter Dudley" <hd...@ho...<mailto:hd...@ho...>> wrote:


Guys,

I remember in one of the telecom it was mentioned that graphical railroad diagrams are generated in the compile process.   Equally good would be Backus-Naur Form grammar descriptions.

Does anyone know where to find the BNF or railroad diagrams for PHDL 2.1?

     Pete Dudley

     hd...@ho...<mailto:hd...@ho...>

     www.HDLGuy.com<http://www.HDLGuy.com>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
phdl-devel mailing list
phd...@li...<mailto:phd...@li...>
https://lists.sourceforge.net/lists/listinfo/phdl-devel

[phdl-devel] BNF or railroad diagrams?

[Peter D. <hd...@ho...>]

Guys,

I remember in one of the telecom it was mentioned that graphical railroad
diagrams are generated in the compile process.   Equally good would be
Backus-Naur Form grammar descriptions.

Does anyone know where to find the BNF or railroad diagrams for PHDL 2.1?  


     Pete Dudley
     hd...@ho...
     www.HDLGuy.com

Re: [phdl-devel] git for PHDL

[Wesley J. L. <wj...@ic...>]

On Wednesday, October 17, 2012 12:07:53 peter dudley wrote:
> Guys I spent some time today learning the git version control program. 
> It has some advantages for collaborative development when compared to
> svn. I found this distribution http://msysgit.github.com/ to be easy to
> install and use. It gives you a bash shell for running git commands. 
> You need to install this first before installing TortoiseGIT anyway.  I
> selected the non-Putty ssh option in the install. I then ran through
> this well written git tutorial,
> http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html  I
> think now I have the necessary skills to interact with a git repo if we
> decide to go that way.   Pete

Also, check out the main Git page <http://git-scm.com> for more tutorials 
(including how-to videos), documentation (including a couple whole free 
online book), and links to Git installers for every platform. The about 
pages <http://git-scm.com/about> outline some of the main advantages of Git, 
but the real power really only comes out once you get used to it and learn 
how to use it really effectively. =)

For Linux you usually just install with a package manager, and with Windows 
you can use either the msysgit (native) version Pete mention, or if you 
already have Cygwin installed, you can install via it's package manager.

There are also a bunch of 3rd party GUI clients (Git comes with it's own 
minimal GUI already) linked on there as well, but I *highly* recommend 
learning the command-line rather than the GUI programs first, as they tend 
to look easy to use, but end up being rather clunky and make it hard to 
learn what you are doing if you aren't familiar with the Git model already.

As far as migration, I've got Git enabled on the SF site, but right now it's 
empty. I think we ought to address our bugs about repository content and 
organization over in SVN, and then migrate just the head files (not the 
whole history) over to Git, leaving SVN around as a historical artifact for 
reference use indefinitely, but not burdening Git with quite as messy of a 
history.

[phdl-devel] git for PHDL

[peter d. <hd...@ho...>]

Guys I spent some time today learning the git version control program.  It has some advantages for collaborative development when compared to svn. I found this distribution http://msysgit.github.com/ to be easy to install and use. It gives you a bash shell for running git commands.  You need to install this first before installing TortoiseGIT anyway.  I selected the non-Putty ssh option in the install. I then ran through this well written git tutorial, http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html  I think now I have the necessary skills to interact with a git repo if we decide to go that way.   Pete 		 	   		  

Re: [phdl-devel] Location for Generated and Other Files

[Wesley J. L. <wj...@ic...>]

On Thursday, October 11, 2012 02:10:15 Brent Nelson wrote:
> It was mentioned yesterday that in cases where documentation or other
> files are automatically generated we don't want to try to put them on
> the wiki.  Rather, Wes suggested we maintain another place to keep them.
> 
> In creating the wiki for PHDL I had need for such a storage place. 
> Specifically, I wanted to have links to source code files on the wiki. 
> I have been storing the files at http://phdl.sourceforge.net/wikifles
> and pointing at that location, but I am not sure this is a good place to
> be doing so.

Really almost anything that we want to link from the wiki or other web pages 
should go into the phdl.sourceforge.net web-site store area. This includes 
images (icons, logos, etc) as well as generated documentation like javadoc 
files.

From a web / wiki user perpective, this makes everything work seemlessly. 
It's also the correct place for this kind of content on sourceforge.

From a project point of view, you can manage files in the PHDL web area 
using an sftp client, which is a little clunky, but keep in mind that in 
generally we don't want anything in the web area that isn't in our version 
control repository, so the usual management operation would just be to run a 
script that runs rsync to synchronize the repository to the web site from a 
repository checkout.
 
> There is a files tab in sourceforge and you can put files there.  But,
> when you use the same URL that your browser shows when looking at the
> files in the web interface it doesn't work.  I have discovered (don't
> remember how) that I can get to the files directly like this:
>                 
> http://iweb.dl.sourceforge.net/project/phdl/wiki/phdllogo.png
> 
> But, I am not sure if this is legitimate to be using.  Finding nothing in
> the docs about this.

The files area is really not meant for any kind of web content; it's meant 
for public releases of our software, big data sets, jarfiles full of 3rd-
party dependencies (BTW, this is actually a really good place to put them to 
make them easy for users to get, but get them out of our repository!), stuff 
like that.

The reason you had to use a funky URL (iweb.dl...) is because you were 
actually direct-linking to a sourceforge file download mirror, which is not 
really a good idea as it's fragile (e.g. it will  will not work if the 
referrer is not set correctly) and is sort of misusing their infrastructure.

I totally understand the want to be able to manage web content *simply*. The 
answer is to get it all into the repository, then rsync it to the project 
web area when there are updates.

This page <https://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web> 
from the sourceforge docs talks about how to use SFTP, SCP, or rsync < 
https://sourceforge.net/apps/trac/sourceforge/wiki/Rsync%20over%20SSH> to 
manage files. Rsync is what we want, because that can be automated by a one-
liner script in our repository and run by any developer to update the web 
content based on repository contents (we probably want to have a "website" 
folder in our VCS just for this purpose -- we could also have a *separate* 
VCS just for the website as an alternative).

(Note that rsync can *also* be used to manage file releases as well as web 
area content, but the file releases area also happens to have a web 
interface.)

To illustrate, here might be a flow to update the web site with new icons 
and updated built documentation after updates have been made in the 
repository to the website or code that has autogenerated documentation made 
from it:

$ git pull (or svn update)
$ make doc (runs doxygen, javadoc, whatever)
$ make push-website (uses rsync to update the web area with repository 
content)

I can help set any of this stuff up or answer any questions.

[phdl-devel] Location for Generated and Other Files

[Brent N. <bre...@by...>]

Going to show my ignorance here…

It was mentioned yesterday that in cases where documentation or other files are automatically generated we don't want to try to put them on the wiki.  Rather, Wes suggested we maintain another place to keep them.

In creating the wiki for PHDL I had need for such a storage place.  Specifically, I wanted to have links to source code files on the wiki.  I have been storing the files at http://phdl.sourceforge.net/wikifles and pointing at that location, but I am not sure this is a good place to be doing so.

There is a files tab in sourceforge and you can put files there.  But, when you use the same URL that your browser shows when looking at the files in the web interface it doesn't work.  I have discovered (don't remember how) that I can get to the files directly like this:                   

                 http://iweb.dl.sourceforge.net/project/phdl/wiki/phdllogo.png

But, I am not sure if this is legitimate to be using.  Finding nothing in the docs about this.

Ideas appreciated.  

By the way,  the motivation for using the files tab in source forge is that they have a nice web browser interface to that area so it is easy to upload files and organize them.  

Brent

[phdl-devel] (no subject)

[Wesley J. L. <wj...@ic...>]

Hey folks,

One important topic we've been speaking about is splitting the PHDL core 
compiler and PHDL Eclipse plugin apart. 
<https://sourceforge.net/p/phdl/bugs/11/>

We certainly don't want to abandon the PHDL Eclipse plugin as long as there 
is someone to maintain it, but I think may of us would much rather focus on 
a simpler compiler that has less dependencies and is easier to maintain. 

I feel strongly that the way to get there is for us to actually define what 
exactly is the PHDL language. Right now it is defined by our implementation, 
but a much better method is to define the language separately 
<https://sourceforge.net/p/phdl/bugs/16/> and have a documented generic 
netlist format with separate converter programs. 
<https://sourceforge.net/p/phdl/bugs/19/>

(You probably want to read those bug links if you haven't already.)

I'd propose the following roadmap:

  1. Create a document that defines how the PHDL compiler currently works 
(Joshua already started documenting the changes between PHDL 2.0 and PHDL 
2.1).
  2. Discuss and modify the above document until it sufficiently describes 
how we want the PHDL language to be. We don't want any major changes at this 
point, but we may need to clarify rules and semantics that currently are 
enforced by the compiler but are not implicit in the grammar.
  3. Add to the above document the definiton of our generic netlist output 
format (e.g. our current XML *.net netlist output is probably a good choice, 
but maybe call it *.phdl_netlist or something).
  4. Once we have the above, we can release it as the "PHDL Language 
Specification v3.0" (skipping v1 and v2, since our current compilers use 
those numbers and we want to not be confusing).
  5. Now, we have the option of doing any or all of the following, possibly 
in parallel, possibly by different folks with different interests:
  * Update the current PHDL 2.1 Eclipse-based compiler to PHDLv3, made to 
output only our generic format.
  * Update the previous PHDL 2.0 plain antlr+java compiler to PHDLv3, made 
to output only our generic format.
  * Create a new C++ implementation, made to output only our generic format.
  * Create a new XYZ implementation, made to ... etc ... you get the idea.
  6. At this point, we have made it possible for any compiler in any 
implementation language or environment to compile the language from .phdl to 
.phdl_netlist; these compilers can share code, or not, whatever best suits 
their implementations.
  7. Convert our current netlist backends to all read from the .phdl_netlist 
format to output their individual formats (e.g. PADS, Eagle, Osmond, Altium, 
ad-hoc statistics generators, whatever people want to make). Like #5, all of 
these can be done, perhaps in parallel, by interested parties, in any 
implementation language they wish.

Advantages to this plan:
  * We get a language spec out of it, which we need long term anyway.
  * Parallel implementations are a sure sign of a more mature language.
  * It devides up the work into modular pieces for easier contributions.
  * It completely decouples frontends and backends for easier maintenance.

Disadvantages to this plan:
  * We may have to temporarily break the current PHDL implementation.
  * There may be a need to forgo partial features that aren't yet finished.
  * We will have (at least temporarily) a less homogeneous code base.

I think the advantages massively outweight the disadvantages. What do you 
guys think?

Re: [phdl-devel] Liveness of branches in SVN

[Joshua M. <jos...@gm...>]

Wes,

I think that would be fine. The RB-2.1-newattr was a copy we made of the
trunk before we got rid of the newattr keyword, which required quite a few
changes to the code. It sounds to me like it would be better to move it to
tags, as well.

Joshua

On Tue, Oct 9, 2012 at 7:03 PM, Wesley J. Landaker <wj...@ic...>wrote:

> On Tuesday, October 09, 2012 18:50:32 Wesley J. Landaker wrote:
> > Hey guys,
> >
> > In SVN we have the following branches:
> >
> >   RB-1.0
> >   RB-2.1-newattr
>
> I see that form our top-level SVN readme these are intended to be release
> branches.
>
> This makes sense for RB-1.0 (although RB-1.x would be a better name for the
> branch, and RB-1.0 would be the tag name).
>
> But I'm not sure what to make of RB-2.1-newattr -- it doesn't sound like a
> release branch, although it's using that naming convention, and both
> RB-2.1-
> newattr and trunk have both phdl-2.0 and phdl-2.1 as sub-directories.
>
> Also, there are no matching tags, so these release branches can't really
> function correctly ...
>
> So anyway, I guess I've discovered the (reasonable) naming convention, but
> I'm still curious about these branches. If there is nothing new in them
> that
> needs to later merged to trunk, I'd suggest we do just move them to tags,
> and not worry about cutting new branches or tags until we've migrated to
> Git.
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel
>
>

Re: [phdl-devel] Liveness of branches in SVN

[Wesley J. L. <wj...@ic...>]

On Tuesday, October 09, 2012 18:50:32 Wesley J. Landaker wrote:
> Hey guys,
> 
> In SVN we have the following branches:
> 
>   RB-1.0
>   RB-2.1-newattr

I see that form our top-level SVN readme these are intended to be release 
branches.

This makes sense for RB-1.0 (although RB-1.x would be a better name for the 
branch, and RB-1.0 would be the tag name).

But I'm not sure what to make of RB-2.1-newattr -- it doesn't sound like a 
release branch, although it's using that naming convention, and both RB-2.1-
newattr and trunk have both phdl-2.0 and phdl-2.1 as sub-directories.

Also, there are no matching tags, so these release branches can't really 
function correctly ...

So anyway, I guess I've discovered the (reasonable) naming convention, but 
I'm still curious about these branches. If there is nothing new in them that 
needs to later merged to trunk, I'd suggest we do just move them to tags, 
and not worry about cutting new branches or tags until we've migrated to 
Git.

[phdl-devel] Liveness of branches in SVN

[Wesley J. L. <wj...@ic...>]

Hey guys,

In SVN we have the following branches:

  RB-1.0
  RB-2.1-newattr

However, looking at the content and the commit history, it looks like these 
are really *tags*, intending to be immutable snapshots of state at some 
point, rather than *branches* intended to have new development done upon 
them for later merging into trunk.

If these really are tags and not branches, I'd like to move them into the 
tags directory to better reflect their true semantics.

Anyone have any thoughts? It might be best if the branch/tag owner(s) took 
care of it, but I can also do it easily.

I won't do anything for a couple weeks, but if I don't get any response, I 
will probably go ahead and move them. (We can always revert the change if we 
later decide it was the wrong thing).

[phdl-devel] Subversion commit hooks fixed & Git migration plan

[Wesley J. L. <wj...@ic...>]

Subverison had some problems with it's commit hooks after it was ported that 
may have been preventing some commits (it was preventing one of mine!) but 
I've just ssh'd in and fixed it.

Speaking of our VCS, we want to migrate over to Git. If you haven't yet 
learned about Git, I'd suggest playing with a bit on your own to make sure 
you understand the basics. Their home page is <http://git-scm.com/>, which 
has links to downloads, documentation, tutorials, etc.

I'd suggest a good migration plan is basically:

  1. Clean up SVN so that the trunk looks just how we want it, minus all the 
cruft, and plus a bunch of good organization.
  2. Copy the head over to Git as a new starting point.
  3. Make a last commit into SVN leaving a note about the new Git location.
  4. Turn SVN into read-only mode.
  5. SVN will stick around indefenitely as a source of historical info.

I probably won't push the migration issue too much, but I'll just warn you 
that if we haven't had any discussion about it or made in tangible progress 
in 6 months, I will probably just jump in and do it. =)

[phdl-devel] Repository urls changed

[Wesley J. L. <wj...@ic...>]

In case anyone is using the repositories and didn't get an e-mail from 
sourceforge, now that we have upgraded the project on their site, the URLs 
for all VCS repositories have changed.

I think you will have to check out new working copies under SVN; you can try 
"svn switch --relocate", but I think the repository UUID may have changed.

For the git repository (empty so far) you just have to change your remote 
configuration, but it's just as easy to just clone again if you don't have 
any local changes.

Re: [phdl-devel] Migration of Web Page to SourceForge wiki

[Wesley J. L. <wj...@ic...>]

On Monday, October 08, 2012 23:18:59 Brent Nelson wrote:
> As a test, I took a cut for a while tonight at copying some of the PHDL
> website info to the source forge wiki, reformatting it for the wiki as I
> went.  I migrated over the Motivation, Installation, Toolchain, and Pubs
> pages.  Pretty easy to do.  Not nearly as powerful as general HTML but
> it seems very adequate for our work.  You can see the pages by going to
> the wiki and clicking the "Browse Pages" button.
> 
> Obviously, there needs to be some kind of table of contents or menu
> section on the home page so people will be able to more easily navigate
> to these pages.  But, this is a start to see if our various individual
> pages can be migrated over and made to look reasonable.
> 
> Comments/suggestions/reactions welcomed.

The really nice thing about the sourceforge built-in wiki is that it's very 
simple and easy to write and maintain. The downside is that it's not as easy 
to host anything, as it the content does have to fit their limited wiki 
model.

One thing to keep in mind is that we don't have to use their built-in wiki 
for everything. We can absolutely have a grand, pretty homepage that looks 
as snazzy and perfect as we want, and just have that link to different 
places on the wiki.

We can also go the other way, and link from the wiki to normal web pages 
hosted on in the sourceforge web area -- take for example autogenerated 
documentation such as what is generated from javadoc or doxygen. That's just 
a matter of running a build nad uploading some files, whereas it would never 
fit appropriately into the wiki model.

So don't feel like we have to move *everything* to the wiki all in mass -- 
but the things that we *do* move over there we get a big advantage in 
simplicity and maintainability.

I think the bottom line is probably along the lines of:

  * Web: when asthetics are important and autogenerated content
  * Wiki: things that should be easy to maintain (i.e. everything else)

The other thing to keep in the back of your mind is that if we ever 
"outgrow" the sourceforge built-in wiki, we can migrate to our own MediaWiki 
(the engine that runs wikipedia) or anything else in the sourceforge web 
area and import all the existing wiki data at any point. I don't recommend 
jumping right into this, because it does take a lot of extra setup and 
maintenance time. But it's nice to know that we can do that if there becomes 
a reason to.

[phdl-devel] Migration of Web Page to SourceForge wiki

[Brent N. <bre...@by...>]

As a test, I took a cut for a while tonight at copying some of the PHDL website info to the source forge wiki, reformatting it for the wiki as I went.  I migrated over the Motivation, Installation, Toolchain, and Pubs pages.  Pretty easy to do.  Not nearly as powerful as general HTML but it seems very adequate for our work.  You can see the pages by going to the wiki and clicking the "Browse Pages" button.

Obviously, there needs to be some kind of table of contents or menu section on the home page so people will be able to more easily navigate to these pages.  But, this is a start to see if our various individual pages can be migrated over and made to look reasonable.

Comments/suggestions/reactions welcomed.

Re: [phdl-devel] Upgrading Sourceforge project

[Wesley J. L. <wj...@ic...>]

On Monday, October 08, 2012 18:58:22 Wesley J. Landaker wrote:
> Some mailers have a special "reply to author" and "reply to list"
> buttons, but they are strictly necessary and the later has to be used

I meant they /aren't/ strictly necessary, of course.

Re: [phdl-devel] Upgrading Sourceforge project

[Wesley J. L. <wj...@ic...>]

On Monday, October 08, 2012 17:25:56 Brent Nelson wrote:
> Thanks for doing this.  Any idea when they will do the upgrade?  I went
> on-line and it said "scheduled".

From what I read, it usually takes anywhere from 5 minutes to 24 hours; some 
of it depends on the size of the data that has to be converted and just when 
the sourceforge system decides to run batches of conversions.
 
> My first task personally will be to move all the web page over to the
> wiki so I can start modifying it.

As soon as the project is upgraded, I'll enable the wiki and you can get 
started! =)

> Also, I hit "reply" to this email and you can see where it went…    Is my
> emailer (Mac Mail) one of the broken ones?

I don't think your mailer is broken. If you just hit "reply" then it did the 
right thing. "Reply" really, truely means to just reply to the author. If 
you want to reply to "everyone" (meaning the mailing list and anyone else 
involved in the conversation, whether they are subscribed or not) you hit 
"reply to all".

Some mailers have a special "reply to author" and "reply to list" buttons, 
but they are strictly necessary and the later has to be used carefully 
because it often cuts off non-subscribed peopple since it typically prunes 
the CC list. So really, on a mailing list you just want to hit "reply to 
all" 99% of the time. Most mailing lists (ours included) are configured not 
to send you two copies of an e-mail if you are both subscribed and in the CC 
list.

Unfortunately a lot of mailing lists really let people get lazy by munging 
the reply-to to force replies to go to the list when someone hits "reply". 
This is bad practice for a lot of reasons, not least of which that it 
violates internet standards. Here are a couple primers:

http://www.unicom.com/pw/reply-to-harmful.html
http://woozle.org/~neale/papers/reply-to-still-harmful.html

[phdl-devel] Upgrading Sourceforge project

[Wesley J. L. <wj...@ic...>]

Just a head's up: I'm upgrading the Sourceforge project 
<https://sourceforge.net/p/upgrade?search=phdl>; once this happens, some 
things will change with some URLs on the site, including the URL for the SVN 
repository.

I'm also going to audit mailing list settings (already did this a little 
with phdl-devel), and will deprecate (later, delete) the phdl-changes list, 
which was handy with Subversion, but really serves little purpose as we 
migrate to Git, since that supports RSS/Atom feeds which are much better 
alternatives for commit notification.

For Git, we want to migrate things over from Subversion, but we really do 
NOT want to just copy things over in mass. Instead, we want to carefully 
copy over only the things that ought to be copied over. Subversion will 
stick around indefinitely as a historical artefact, but we really don't want 
Git to contain so much cruft (e.g. compiled or generated code; 3rd-party or 
non-project code; outdated old history files, etc).

[phdl-devel] Inviting folks from phdl-support

[Wesley J. L. <wj...@ic...>]

We have had quite a few people post one or more messages to the phdl-support 
list via the web site form. It might be a good idea to e-mail these people 
and invite them to join the phdl-devel list if they are interested in 
continuing to follow or contribute to the design and development of PHDL.

I was going to do it myself, but I can't get the e-mail addresses of the 
posters through the normal sourceforge archive interface (it obscures them 
in the display), so I'd have to go through mailman, I don't have the admin 
password and didn't want to change it out from under anybody! =)

Any volunteers to do this?

[phdl-devel] Near-term through 2013 plans

[Wesley J. L. <wj...@ic...>]

In bug #3574983 ("Split between Core and Eclipse") 
<https://sourceforge.net/tracker/index.php?func=detail&aid=3574983&group_id=547684&atid=2223110>, 
I've captured the idea of updating the architecture to have a split between 
PHDL Core and the PHDL Eclipse Plugin.

I posted another bug, bug #3575344 ("Need canonical language documentation") 
<https://sourceforge.net/tracker/?func=detail&aid=3575344&group_id=547684&atid=2223110>, 
which I think is a first step to making this kind of split feasible without 
relying on implementation-dependent behavior.

Obviously there are lots of other bugs we need to address, but I think these 
two really are a critical pair. We're due for our last telecon soon, so we 
may want to have that first before we get into a long discussion on phdl-
devel.

I'd suggest that everyone at least start thinking about this stuff a little 
bit as we move into the beginning of what is most likely a long term, 
unfunded project phase.

I'm also interested in hearing what people think their involvement in 2013 
might be. I suspect that we are losing some folks as they go off into other 
interesting endeavors. I know at least Pete and I are planning to stick 
around for the long term, but some of the choices we have to make depend 
largely on who is interesting in continuing involvement!

Re: [phdl-devel] Admin bugs

[Brent N. <bre...@by...>]

Wes, thanks for posting these.  Just what we need.  Many of them are things I have noted need fixing but still coming up to speed on the mailing list and other SF things.

I assume the mailing list is the right place to discuss them?  

If so, regarding the phdl-devel and phdl-support lists, anyone have problems with my taking the enhancement requests on phdl-support, transferring those suggestions to the tracker, and then deleting the phdl-support list?  Then, phdl-devel will be THE list going forward.  Thought I would ask before I leap...










On Oct 5, 2012, at 9:13 PM, Wesley J. Landaker wrote:

> Guys,
> 
> I started filing a few bugs in the sourceforge tracker about
> administration issues, particularly some minor stuff about the web page
> and mailing list.
> 
> This is probably the best way for us to capture issues going forward as
> this scales and transitions much better than phone calls or private e-mails.
> 
> I'd encourage everyone else to get their laundry list into the bug
> tracker as well. Remember, just because it's in the bug tracker doesn't
> mean that anybody HAS to do it. But it's an excellent way to triage,
> track, discuss and remember issues that come up.
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> phdl-devel mailing list
> phd...@li...
> https://lists.sourceforge.net/lists/listinfo/phdl-devel

Re: [phdl-devel] Presentation Slides Posted

[Wesley J. L. <wj...@ic...>]

On 10/03/2012 11:11 PM, Brent Nelson wrote:
> A new PDF file of a PHDL presentation made last week at the PCB West
> conference has been posted to the PHDL website under the "Pubs" tab.

Thanks for posting this. These slides are compelling, so hopefully they
generated some interest in the project. It's good to make these (and any
other materials we can) as available to the public as possible.

[phdl-devel] Admin bugs

[Wesley J. L. <wj...@ic...>]

Guys,

I started filing a few bugs in the sourceforge tracker about
administration issues, particularly some minor stuff about the web page
and mailing list.

This is probably the best way for us to capture issues going forward as
this scales and transitions much better than phone calls or private e-mails.

I'd encourage everyone else to get their laundry list into the bug
tracker as well. Remember, just because it's in the bug tracker doesn't
mean that anybody HAS to do it. But it's an excellent way to triage,
track, discuss and remember issues that come up.

[phdl-devel] Presentation Slides Posted

[Brent N. <bre...@by...>]

Hello All,

A new PDF file of a PHDL presentation made last week at the PCB West conference has been posted to the PHDL website under the "Pubs" tab.  

Feedback welcomed! 

Brent Nelson