bibliocello sample site available
Dale Henrichs
state of bibliocello. As mentioned on the front page, this is very much
an experimental site (broken links and inconsistent UI should be
expected:)...the main things of interest are the structured repositories
and source search...
The sample Pharo project:
http://a-bibliocello.gemstone.com/bibliocello/Pharo
shows a possible structure for the pharo project repositories ... with
multiple repositories associated with a procet, nesting the repositories
in a directory structure should make related repositories easier to find.
For Seaside 3.0, I'm showing a different directory structure for
repositories:
http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0
Currently the search box will search from the currently repository
through all child repositories. If you go to an mcz file page:
you can search a single mcz file.
As you can guess, I've loaded up the some of the repositories with mcz
files:
http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0/repository/Versions/3.0.0-rc.1/gemstone
http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0/repository/Versions/3.0.0-rc.1/pharo
http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0/repository/Versions/3.0.0-rc.1/squeak
http://a-bibliocello.gemstone.com/bibliocello/Pharo/repository/Versions/1.0
http://a-bibliocello.gemstone.com/bibliocello/GLASS/repository/Versions/1.0-beta.8
http://a-bibliocello.gemstone.com/bibliocello/GLASS/repository/Versions/1.0-beta.9
From the home page, search will search through all of the mcz files
that have been stored in the system (284 mcz files as of today).
While this is a public site, I don't consider this a public
announcement, feel free to share with folks who are interested in
bibliocello, but I _will_ be taking the site up and down and blowing the
contents away so nothing should be put on the site that isn't backed up
somewhere else.
You can log in (if you need help figuring out the credentials, send me
email:) and play with the look and feel for projects, you can connect to
the repositories from a Monticello browser ...
Hopefully, the site will generate some discussions and we can talk about
dong some concrete things ...
Dale
Sean Allen
win over squeaksource.
What is the search 'Implementors' ?
Is it in the plans to have a side wide search?
Ability to view source from the browser?
Dale
On Aug 7, 8:13 am, Sean Allen <s...@monkeysnatchbanana.com> wrote:
> Just the addition of a summary about each project is a huge usability
> win over squeaksource.
>
> What is the search 'Implementors' ?
implementors lists the methods whose selector matches the pattern ...
regular Smalltlak implementors...
The search scope (so far) is at the site-level, project, repository
and package.
> Is it in the plans to have a side wide search?
> Ability to view source from the browser?
also dipslaying source on the site ... I'm not using a browser at the
moment .. the source is displayed as a tree view ... I've also got
syntax highlighting enabled...
>
> On Thu, Aug 5, 2010 at 5:33 PM, Dale Henrichs <dhenr...@vmware.com> wrote:
> > Head on over tohttp://a-bibliocello.gemstone.com/to see the current state
> > experimental site (broken links and inconsistent UI should be
> > expected:)...the main things of interest are the structured repositories and
> > source search...
>
> > The sample Pharo project:
>
> > http://a-bibliocello.gemstone.com/bibliocello/Pharo
>
> > shows a possible structure for the pharo project repositories ... with
> > multiple repositories associated with a procet, nesting the repositories in
> > a directory structure should make related repositories easier to find.
>
> > For Seaside 3.0, I'm showing a different directory structure for
> > repositories:
>
> > http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0
>
> > Currently the search box will search from the currently repository through
> > all child repositories. If you go to an mcz file page:
>
> > you can search a single mcz file.
>
> > As you can guess, I've loaded up the some of the repositories with mcz
> > files:
>
> >http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0/repository/V...
> >http://a-bibliocello.gemstone.com/bibliocello/Seaside3.0/repository/V...
> >http://a-bibliocello.gemstone.com/bibliocello/Pharo/repository/Versio...
> >http://a-bibliocello.gemstone.com/bibliocello/GLASS/repository/Versio...
> >http://a-bibliocello.gemstone.com/bibliocello/GLASS/repository/Versio...
Sean Allen
>
>
> On Aug 7, 8:13 am, Sean Allen <s...@monkeysnatchbanana.com> wrote:
>> Just the addition of a summary about each project is a huge usability
>> win over squeaksource.
>>
>> What is the search 'Implementors' ?
>
> You can see for yourself - the search boxes are functional.
> implementors lists the methods whose selector matches the pattern ...
> regular Smalltlak implementors...
>
> The search scope (so far) is at the site-level, project, repository
> and package.
>
I tried searching. Didnt get any results. Will try again now I understand
what I would want to put in to see...
>> Is it in the plans to have a side wide search?
>> Ability to view source from the browser?
>
> Like I said, the search site-wide search function is operational. I am
> also dipslaying source on the site ... I'm not using a browser at the
> moment .. the source is displayed as a tree view ... I've also got
> syntax highlighting enabled...
>
Can you give me a couple sample search string that would demonstrate all that?
I spent a while plugging things in and never discovered any of that.
Sean Allen
I think actually I should step back and ask a question. What do you
mean by site wide search?
I meant a search where you wouldnt have to put implementator or source
or anything else but
if you put in Dale as a string, it would find all instances in stored
source, wiki, news etc of Dale.
Dale
'implementors' and press the button ... you'll get back a number of
methods with the string 'grease' in the selector.
On Aug 8, 12:57 pm, Sean Allen <s...@monkeysnatchbanana.com> wrote:
Sean Allen
why that never occurred to me, i don't know. i guess because i was thinking
on a project rather than code level.
Dale
that an advanced search page would allow one to choose the contexts
that are to be searched ... I think we very quiickly get into UI
design territory we could filter results (after the fact) or filter
the search (before the fact) ... I'm not a UI guy .. I'm going to be
agnostic when it comes to the UI and let folks with skills there solve
those problems...that won't stop me from doing something quick and
dirty and ugly to expose capabilities ... there's a fair amount of
information that you want/need to track when you're searching through
the code base ... I'd like to expose multiple versions of a method/
class and provide information about which package(s) the definition
appears in ... I'd like to search from within the context of a
metacello configuration ... essentially providing many of the same
tools you expect to have in your smalltalk image except the tools are
expanded to encompass multiple versions of methods and packages that
are not loaded into your image, including even source from different
Smalltalks ....
Naturally this leads to wanting to do diffs between various
contexts .... again there is the how do you do the diffs (and against
what) and how you display the results ... both interesting problems
and both requiring good solutions...
Dale
On Aug 8, 1:02 pm, Sean Allen <s...@monkeysnatchbanana.com> wrote:
> On Sun, Aug 8, 2010 at 3:57 PM, Sean Allen <s...@monkeysnatchbanana.com> wrote:
Dale
On Aug 8, 1:15 pm, Sean Allen <s...@monkeysnatchbanana.com> wrote:
> i feel daft btw for not realizing that it was implementors of a message.
> why that never occurred to me, i don't know. i guess because i was thinking
> on a project rather than code level.
>
Sean Allen
heart that I'm not.
From a general 'exploration' side, I find github to be fairly easy to
explore code from.
There isnt too much there that is revolutionary, it many ways it is
like cvs-web all
grown up... but the network graph of how changes came together from different
branches, forks etc is a big win. Something like that would be very
nice for bibliocello.
Have you thought about whether adding social aspects? Ability to have an account
and track other people's or simply the ability to create your own fork
that others could then
follow etc etc.
I have talked to a few people who have mentioned wanting to see a
'github for monticello'.
Thus, the questions.
Basically, most of my questions are just getting an idea of what your
ideas for bibliocello.
Dale
lot of time using web-based tools .... so I don't have knowledge of a)
the palette of possible tools nor b) that site x has neat feature y.
With that said, I know that without a database with multiple versions
of something, it's dang hard to draw a code fork graph:)
I don't have a specific vision for bibliocello from the functionality/
UI view. Pier is intriguing because it provides a framework for easily
plugging in tools ... if someone develops a code fork graph, then it
could be published as part of a bibliocello site and foks could then
add the code fork graph to their project ...
I have built the basic database out of MCDefintions (class definitions
and method defintions) the bulding block for the mcz file. I have
started experimenting with handling multiple versions of mcz files
(for an example go to:
http://a-bibliocello.gemstone.com/bibliocello/example
and do a 'foo -configuration' (without quotes) source search...
I have a vision that there should be 'remote repositories references'
and the ability for networks of bibliocello sites to do do queries/
etc. between sites ... I think that these are important building
blocks...I want to preserve the distributed nature of SqueakSource...I
think that bibliocello is about expanding the notion of the repository
from just a place to store bits to a place to store additional (all?)
info about the project (issues/documentation/code) and to provide
tools for manipulating and mining that information...
Dale
On Aug 8, 1:33 pm, Sean Allen <s...@monkeysnatchbanana.com> wrote:
> Sometimes I wish I was a UI guy. I read alot about it but I know in my
> heart that I'm not.
>
> From a general 'exploration' side, I find github to be fairly easy to
> explore code from.
> There isnt too much there that is revolutionary, it many ways it is
> like cvs-web all
> grown up... but the network graph of how changes came together from different
> branches, forks etc is a big win. Something like that would be very
> nice for bibliocello.
>
> Have you thought about whether adding social aspects? Ability to have an account
> and track other people's or simply the ability to create your own fork
> that others could then
> follow etc etc.
>
> I have talked to a few people who have mentioned wanting to see a
> 'github for monticello'.
> Thus, the questions.
>
> Basically, most of my questions are just getting an idea of what your
> ideas for bibliocello.
>
Dale
I am tackling search, because it is something that I do a fair amount
and I wish that I could get more info more easilyt. I routinely keep 2
or 3 pharo images and 2 gemtools image (with access to dozens of GLASS
versions) that I refer to when I need to look up some code ... so for
me being able to have a single site where I can do semantic searches
(references/defintions/implementors/senders) for all of the code that
I'm interested in (including multiple versions) would scratch a big
itch for me.
I'm interested in hearing from you the things that _you_ need/want.
Dale
On Aug 8, 1:33 pm, Sean Allen <s...@monkeysnatchbanana.com> wrote:
> Sometimes I wish I was a UI guy. I read alot about it but I know in my
> heart that I'm not.
>
> From a general 'exploration' side, I find github to be fairly easy to
> explore code from.
> There isnt too much there that is revolutionary, it many ways it is
> like cvs-web all
> grown up... but the network graph of how changes came together from different
> branches, forks etc is a big win. Something like that would be very
> nice for bibliocello.
>
> Have you thought about whether adding social aspects? Ability to have an account
> and track other people's or simply the ability to create your own fork
> that others could then
> follow etc etc.
>
> I have talked to a few people who have mentioned wanting to see a
> 'github for monticello'.
> Thus, the questions.
>
> Basically, most of my questions are just getting an idea of what your
> ideas for bibliocello.
>
Sean Allen
When looking at the project list, i see plenty of projects with no
simple description,
so you have to click in and hope the wiki has some info...
here is an example...
http://www.squeaksource.com/MaPro.html
I have no idea what it is. from the project list, unless it has a good name.
i don't know. MaPro has no wiki entry so it is even worse.
Lets take something I happen to know what it is...
Aconcagua
in the project list. no info is displayed. i can click to the wiki and
get an idea
but unless i know that is what I want, I'm pretty well screwed.
Discovery takes a really long time.
More means of discovery would be nice. Even when I look by tag which
helps, the lack of a summary makes
looking way to hard.
Another:
I can see code for any particular version but I can't diff it against
other versions to see what changed from the ancestor
or from some other ancestor ( perhaps I'm using FooBar-27 and there is
a new FooBar-30 and I want to see what has changed. ).
There is no way to do this without firing up an image. I dislike that
I have to switch tools to do that.
Another still:
No network graph. I'd like to be able to look and at least see in this
repository that FooBar-27-STA split into
FooBar-28-Joe and FooBar-28-Ed and that FooBar-28-Joe dead ends but
the branch that started at FooBar-28-Ed has had
additional work that continued on.
Another that you already have covered:
The urls that you get when you browse timeout. I hate having something
open, returning an hour later, hitting the link and being taken
back to the root of SqueakSource to start over. RESTish urls are a
massive boon here. There isn't any real session info that is of
interest
when using SqueakSource. A more restful design would be a big boon.
Another:
The browse interface while nice and smalltalk toolish is a little slow
and sluggish with its full page reload. Access to all the source
would be nice. Then I can scan and review more quickly. Or perhaps
just the same style interface but more responsive, more ajax-y would
cover it.
Another:
Project activity - its a color code. I never found a meaning anywhere
for what the color code means. If you are going to use a color for a
legend, the legend on the same page would be really nice. In general I
have lots of little UI issues like this.
Another:
As far as I can tell, the top level grouping is by project- each
project has a repo. I like the general github idea of by user more.
For example, lets say that you and I are working project Bilbliocello.
We have a mainline branch for final code which is maintained by you
and I'm working on my own branch where I make radical changes. It is
still bibliocello but it is my version. Under squeaksource, I can
either start a new project or comingle mine into yours. I prefer the
Sean -> Bibliocello idea from github and similar to the Squeaksource
idea of Bibliocello as the base method of organization.
Another:
I really like in other systems, the ability to 'watch' different
projects/repositories so, I could 'watch' bibliocello even if I'm not
working on it and have a nice dashboard that collects all changes,
commits etc to the different projects i'm interested in, in one place.
Then i can just login and see what has changed for each.
Another:
Metacello is much better than monticello. Squeaksource is just
monticello. Being able to see metacello info in a tool like different
versions etc would be excellent.
Some of the above are already addressed in bibliocello. Some might
actually not be issues in squeaksource, but I just don't know it well
enough because I always get frustrated with it and walk away shaking
my head. In general, I find there is much to like in github,
bitbucket, assembla et al and wish many of those features excited in a
Smalltalk project hosting system.
Dale
Excellent ... now this is what I'm talking about ...
I'm not going to comment on each item ... at this point I'd like to
hear more about specific problems that folks are having ...
Some of the items point towards framework issues (having both user-
centric and project-centric features) some point to generic UI issues
(RESTful links and better/different browsers) and some point to
specific tools (network graph and differencing)....
I've said it before (and I'll say it again)..I like the idea of having
a palette of tools (using the Pier framework) ... with a user-centric
approach, an individual can choose the code browser/difference browser/
network grapher tool that he/she prefers to use/see ... if you don't
like a particular tool you can write your own:)
This starts sounding like a duplication of the in-image tools and to a
certain extent it is...but bibliocello isn't a site for doing
development (no code writing/debugging) it's a site for doing research/
management tasks based on an extensive library of code and as a result
will have a certina set of tools in common...
Dale
Norbert Hartl
The time I spent was looking at the structure of projects > repositories > files. The long URLs disturbed me a little. And so I started to think about the relationships between those entities. But no outcome so far.
If you are collecting ideas. I can subscribe to a lot what Sean said. I like to able to
content
- project wiki with summary, project descriptions and how-tos
- probably integrate Pier-Book for writing manuals
- tool for showing timeline (package upgrades, notes changes, ticket status change etc.) I love this in trac
code
- see the difference between two versions
- be able to browse a package
- Lint/slime integration
remote interface
- to link to a certain method (REST). So I can write mails to the mailing list "look here ->>"
- have an update stream on my projects. This could be plain RSS so I know always what happens in my projects. And I could make my hudson server know that there is something to do
- annotate packages in my project. If there was a successful hudson run than I could annotate the package as tested or something like that
- link a package in a foreign repository (including to be able to see diffs etc.)
- I don't know if it is feasible to create an issue tracker. But either that or a remote usage of e.g. google code (if that is possible)
metacello
- browse metacello configuration
- probably construct dependencies from the UI or complete metacello configurations
analysis
- see dependencies of my packages
- have warnings on cyclic dependencies
- integrate some of the other moose tools, too. From moose over mondrian you can generate bitmap images (or better svg)
None of them are well thought but that's what I'm thinking at the moment.
Norbert