Announcing the development of LIBSTOCK - Your place for code

[anikolic]

Thank you for participating in discussion.

We have though of it this way: Libstock is primarily a Library Stock, a place to share, and eventually sell libraries. But it was hard to find the right syntax which can describe that you are not only allowed to place your custom library there, but you are encouraged to write documentation and provide examples for your libraries too. We provided the means to provide your own marketing for your library and to draw more attention by writing blog about it and use your presentational skills to convince people to use your library over all others.

We thought of this omnibus of user activities related to the library as a "user project". So your "project" is a library and other related material, such as examples, documentation, blog with videos and picture galleries.

It is possible that we didn't use the best possible syntax for this, so we invite you to share your ideas on this, and help us find the right words that will satisfy it all.

Best regards,
Aleksandar

[janni]

We have though of it this way: Libstock is primarily a Library Stock, a place to share, and eventually sell libraries.

Thanks , that makes the intentions clear. But, intentions may be easily overruled by users - we have seen this happen with User Projects forum which transformed from finished project presentation/discussion forum into 'help me with my current project' one. (While, as most users seem to have strict programming language preference, asking for help in language-oriented forum makes much more sense.)

Carefully choosing words may be decisive in preserving intended character of Libstock. Note that present nomenclature already induced doubts - even in those that knew the assumptions that were behind creation of this webpage.

Replacing 'PROJECT' with 'LIBRARY' in main titles should make things clear (for example, requesting a project on library page seems to have little sense), but then there's one problem - as any library may be acompanied by a number of example projects and one project may use more than one lib, there should be also a way to browse projects (makes the terminology even more important, doesn't it?).

[joseLB]

Hi Marko
Thanks, seems that it will be very interesting. Follows some suggestions/questions:
1- wy not to put it in beta outside ME, before start it? Maybe in a more "hidden" address?
2- as lucca suggested, a bit more description, searcheable, would be good.
Maybe a questionarie with some questions (to help to organize the info), like objectives, keywords, libs, algorithms, that is, what the project do in short. They are not required, but incentived to fill.
3- the categories -> where I would put something like a POV (persistence of vision) project? And a mini-mini project that is a set of routines to read/write to a led mouse chip, like ADNS? robotics? motor control? So, this is a growing list. We will be able to create categories? I don't think it's a good thing, but...
that
that's all for now
Jose

[anikolic]

Replacing 'PROJECT' with 'LIBRARY' in main titles should make things clear (for example, requesting a project on library page seems to have little sense), but then there's one problem - as any library may be acompanied by a number of example projects and one project may use more than one lib, there should be also a way to browse projects (makes the terminology even more important, doesn't it?).

This is exactly the thing which we tried to put in a single word. Libstock is a place for code. That's the main assumption. Secondly, it's a place for libraries. Thirdly, it's a place for examples and projects. And above all else, you can have your own marketing with the new BLOG section. Having it all in one place doesn't seem as a bad idea, if we can put it in right categories and mark it with the right tags. The website has clear markings whether the "project" contains compiled libraries (LIB), source code of the libraries (SRC), examples (EXA), Help files (HLP), ready-to-use HEX files (HEX), connection schematics (SCH), complete PCB for development (PCB) and other related documents (DOC). We have also introduced filters in the category listings, so you can also filter only those projects that contain Libraries, or only those with Examples, or both libraries and examples. We can also make all sorts of filters that can facilitate the users quest for the right material.

Janni and others that defend Libstock as just a place for libraries, can you please share your thoughts on what do you think will be lost if Libstock retained the "Project" terminology over the "Library" terminology. We want to have this discussion now, so we can make the right call based on what community really needs.

Thank you in advance!

Best regards,
Aleksandar

[Dany]

Replacing 'PROJECT' with 'LIBRARY' in main titles should make things clear (for example, requesting a project on library page seems to have little sense), but then there's one problem - as any library may be acompanied by a number of example projects and one project may use more than one lib, there should be also a way to browse projects (makes the terminology even more important, doesn't it?).

This is exactly the thing which we tried to put in a single word. Libstock is a place for code. That's the main assumption. Secondly, it's a place for libraries. Thirdly, it's a place for examples and projects. And above all else, you can have your own marketing with the new BLOG section. Having it all in one place doesn't seem as a bad idea, if we can put it in right categories and mark it with the right tags. The website has clear markings whether the "project" contains compiled libraries (LIB), source code of the libraries (SRC), examples (EXA), Help files (HLP), ready-to-use HEX files (HEX), connection schematics (SCH), complete PCB for development (PCB) and other related documents (DOC). We have also introduced filters in the category listings, so you can also filter only those projects that contain Libraries, or only those with Examples, or both libraries and examples. We can also make all sorts of filters that can facilitate the users quest for the right material.

Janni and others that defend Libstock as just a place for libraries, can you please share your thoughts on what do you think will be lost if Libstock retained the "Project" terminology over the "Library" terminology. We want to have this discussion now, so we can make the right call based on what community really needs.

Thank you in advance!

Best regards,
Aleksandar

Hi, some thoughts...
I also do think that a very clear difference between a "project" and a "library" is needed (by stating e.g. a "category" of the software contribution), so I am not in favor of calling everything a "project":

e.g.
LibStock
- "library" (mcl) with optional additions (src) (exa (src)(hex)) (hlp) (sch) (pcb) (doc) **
- "project" with optional additions (.mcl) (src) (hex) (hlp) (sch) (pcb) (doc) ***
- article???

Each "category" can contain above optional additions.

** : also each "example" can have a hex file and multiple source files.
*** : each project can have multiple files (with e.g. .mcl and source file).

In English:
A contribution to libstock is either
- a "library" (whatever that is, see next point), with optionally its source files, usage examples etc...: the item actually delivered here (if I may use mP terms) is a "unit file", not a main project file (so things like in the library manager).
- a "project" with optionally its source files, usage examples etc...: the item actually delivered here (if I may use mP terms again) is a "project file".
- something else to be defined in the future?

* But: the term "library", does that reflect one pascal unit (or C file) or a number of units (or C files)? Some "libraries" can have more "units", e.g. USB: HID unit, CDC unit, Common unit etc...
I might be needed to allow more than one unit in a "library" (as there should be allowed more than 1 source files in a project). Each unit can have then its .mcl file, source file, help file etc...

* What about the usage of the package manager to distribute "libraries"? Or will both methods be supported (delivery in package and delivery with separate .mcl , source, help etc files)?

* Will there a possibility to build e.g. a "usage tree", e.g. which LibStock projects or LibStock libraries do use other LibStock libraries? It can not be the purpose to publish all used libraries in all projects that use them (that is why libraries exist!). Of course, files that do belong to a project (and that are no libraries) have to be included with the project.

* Looks very nice though! Look forward to it.

[anikolic]

In English:
A contribution to libstock is either
- a "library" (whatever that is, see next point), with optionally its source files, usage examples etc...: the item actually delivered here (if I may use mP terms) is a "unit file", not a main project file (so things like in the library manager).
- a "project" with optionally its source files, usage examples etc...: the item actually delivered here (if I may use mP terms again) is a "project file".
- something else to be defined in the future?

So, you are suggesting that we force users to specify the main purpose of their code - whether it's a project or a library. If I understand well, if it's mainly a library all other provided code is to demonstrate the library functionality, and if it's a project, libraries inside are considered just a necessary part of the project.

* But: the term "library", does that reflect one pascal unit (or C file) or a number of units (or C files)? Some "libraries" can have more "units", e.g. USB: HID unit, CDC unit, Common unit etc...
I might be needed to allow more than one unit in a "library" (as there should be allowed more than 1 source files in a project). Each unit can have then its .mcl file, source file, help file etc...

This is not a problem. Code is uploaded either in .ZIP, .RAR or Package manager form (.MPGK). mikroElektronika is not responsible, nor controls the content of the archives that user provides. It will be clearly stated in "Terms and conditions". Multiple sources or libraries as part of a more complex library are allowed.

* What about the usage of the package manager to distribute "libraries"? Or will both methods be supported (delivery in package and delivery with separate .mcl , source, help etc files)?

Package Manager is the main and preferred way of distributing your code. But for the sake of part of the community which will provide just projects, we have decided to allow .ZIP and .RAR archives as well.

* Will there a possibility to build e.g. a "usage tree", e.g. which LibStock projects or LibStock libraries do use other LibStock libraries? It can not be the purpose to publish all used libraries in all projects that use them (that is why libraries exist!). Of course, files that do belong to a project (and that are no libraries) have to be included with the project.

Currently, we haven't supported this option, but you can always explain this in your blog section, and description section.

* Looks very nice though! Look forward to it.

Thanks

Best regards,
Aleksandar

[Dany]

In English:
A contribution to libstock is either
- a "library" (whatever that is, see next point), with optionally its source files, usage examples etc...: the item actually delivered here (if I may use mP terms) is a "unit file", not a main project file (so things like in the library manager).
- a "project" with optionally its source files, usage examples etc...: the item actually delivered here (if I may use mP terms again) is a "project file".
- something else to be defined in the future?

So, you are suggesting that we force users to specify the main purpose of their code - whether it's a project or a library. If I understand well, if it's mainly a library all other provided code is to demonstrate the library functionality, and if it's a project, libraries inside are considered just a necessary part of the project.

Indeed.

* But: the term "library", does that reflect one pascal unit (or C file) or a number of units (or C files)? Some "libraries" can have more "units", e.g. USB: HID unit, CDC unit, Common unit etc...
I might be needed to allow more than one unit in a "library" (as there should be allowed more than 1 source files in a project). Each unit can have then its .mcl file, source file, help file etc...

This is not a problem. Code is uploaded either in .ZIP, .RAR or Package manager form (.MPGK). mikroElektronika is not responsible, nor controls the content of the archives that user provides. It will be clearly stated in "Terms and conditions".

* What about the usage of the package manager to distribute "libraries"? Or will both methods be supported (delivery in package and delivery with separate .mcl , source, help etc files)?

Package Manager is the main and preferred way of distributing your code. But for the sake of part of the community which will provide just projects, we have decided to allow .ZIP and .RAR archives as well.

Clear.

* Will there a possibility to build e.g. a "usage tree", e.g. which LibStock projects or LibStock libraries do use other LibStock libraries? It can not be the purpose to publish all used libraries in all projects that use them (that is why libraries exist!). Of course, files that do belong to a project (and that are no libraries) have to be included with the project.

Currently, we haven't supported this option, but you can always explain this in your blog section, and description section.

That is a pity. This is a problem on my own website too, and I do not know how to solve it in a decent way. I hoped You had some more ideas as in the library documentation (Library dependany tree), but automated then.

* Looks very nice though! Look forward to it.

Thanks

Best regards,
Aleksandar

[anikolic]

OK, Dany, thanks for sharing your thoughts on this. I will see with Marko if it is possible to easily add this functionality of choosing whether the code is a projects or a library when it is uploaded on the website. It's more of a technical thing now, then our determination to do this. We want to get the libstock up and running soon, and we will see if database structure can be changed in such a way in a short period of time.

If this requires a bit more time, we will release the website as is, and introduce this feature as soon as possible, and users can later specify what category their code belongs to.

Best regards,
Aleksandar

[stevenindon]

Dany,

Good point and very well defined. I guess dany has got what we have talking all this while. As a developer, i feel that libraries are rather more important than project examples..and they should be totally serperated.

It will be a great idea to put a shortcut link in compilers to list all usable library mcl files from libstock if possible...or a link to the website maybe..

[Dany]

OK, Dany, thanks for sharing your thoughts on this. I will see with Marko if it is possible to easily add this functionality of choosing whether the code is a projects or a library when it is uploaded on the website. It's more of a technical thing now, then our determination to do this. We want to get the libstock up and running soon, and we will see if database structure can be changed in such a way in a short period of time.

Please do not delay anything due to my "thoughts" . I am very sure LibStock will be very usable as it is defined now.

If this requires a bit more time, we will release the website as is, and introduce this feature as soon as possible, and users can later specify what category their code belongs to.

This approach would be preferrable I think. A lot of people are waiting to have LibStock!

Thank you for considering my proposals!

[anikolic]

Dany,

Good point and very well defined. I guess dany has got what we have talking all this while. As a developer, i feel that libraries are rather more important than project examples..and they should be totally serperated.

It will be a great idea to put a shortcut link in compilers to list all usable library mcl files from libstock if possible...or a link to the website maybe..

Actually, Libstock is powerful enough already to provide the infrastructure for both libraries and projects. Technically speaking the problem we are dealing with is just adding a simple flag in the project table in the database that will distinct the project from a library. This is easy to do, we just have to see how will this affect search and filters.

We have a special plan for integration of Libstock in compilers, but we cannot just yet talk the details until the Libstock is completely defined as a community website.

Best regards,
Aleksandar

[stevenindon]

Anikolic,

Actually, Libstock is powerful enough already to provide the infrastructure for both libraries and projects.

I am sure they are. As dany has just said by using the term 'project' will confuse users that this is just another web of project examples. And project examples are more likely confuse users of some very specific examples made for some specific project.

Library has a very different defination - its a collection of reusable function that can be included into your project that does some specific routine for some specific device. Like a plugin.

Mikroe compilers has great user interface, very very user friendly and yet so powerful. With additional of more libraries from users will draw more developers to join in.

[janni]

Libstock is a place for code. That's the main assumption. Secondly, it's a place for libraries. Thirdly, it's a place for examples and projects.

Things are getting clearer by the minute .

Janni and others that defend Libstock as just a place for libraries, can you please share your thoughts on what do you think will be lost if Libstock retained the "Project" terminology over the "Library" terminology.

I don't think I opposed to expanding Libstock over just collection of libraries for mE compilers . I just wouldn't like it to become a big basket for everything. That would indeed disappoint me as the name Libstock suggested that code libraries would actually form the main part of this website. (And I would have really not liked it if Libstock turned into a place for ongoing user projects with the same problems repeating over and over - forums are better suited for this.)

Note however, that I do not speak of libraries in the specific context of mE compilers, like you seem to assume or Dany specified (i.e. units, modules). Code library may be in fact any code dedicated to some particular task (and one may always convert it to mE compiler library ). Naturally, it should be code useful to others as a basis for their projects.

As Dany pointed out, project may be understood as defined in mE compilers. On the other hand, almost any piece of work that is undertaken may be called a project. So, we'd either have a very narrow or very wide meaning of project and both misleading. It would probably be most practical to reserve the word 'project' to mE compilers' projects as most Libstock visitors will come from mE forums.

Naturally, one may also reserve the word 'library' to the meaning it has in mE compilers and use 'code' for all the titles in Libstock. It doesn't sound bad in this context (share code, request code, etc.) and there's already 'Code categories' in use.

At least nobody will think to place strictly hardware project on Libstock (like how to connect a LED to a processor) or regard it a place for just user projects for mE compilers.

We have a special plan for integration of Libstock in compilers, but we cannot just yet talk the details until the Libstock is completely defined as a community website.

Well, if it is so, then keeping mE compilers nomenclature is crucial. Project should stay as compiler project and library as a separate piece of code prepared for use with Package Mananger. Any other code will be just code, for use in a project or to be inserted into a library.

Actually, Libstock is powerful enough already to provide the infrastructure for both libraries and projects. Technically speaking the problem we are dealing with is just adding a simple flag in the project table in the database that will distinct the project from a library.

Then it should be no problem to have three categories . Libraries, projects, and other code.

And above all else, you can have your own marketing with the new BLOG section. Having it all in one place doesn't seem as a bad idea, if we can put it in right categories and mark it with the right tags. The website has clear markings whether the "project" contains compiled libraries (LIB), source code of the libraries (SRC), examples (EXA), Help files (HLP), ready-to-use HEX files (HEX), connection schematics (SCH), complete PCB for development (PCB) and other related documents (DOC). We have also introduced filters in the category listings, so you can also filter only those projects that contain Libraries, or only those with Examples, or both libraries and examples. We can also make all sorts of filters that can facilitate the users quest for the right material.

All this sounds very good - especially the filters .

[p.erasmus]

All of this sound good and fine ,However I suspect this is going to be a place were mE can place some special developed Libraries
for the use of the users however at a Price it will be Libraries seen by mE as not part of the compilers and therefore the user have to pay for them .!!

This Libstock is not there for the benifit of the mE compiler soley as we are made to believe !! I am not so optomistic anymore regarding Libstock ,this became clear when I read the post that FAT32 Lib will not be part of the compilers !!

[anikolic]

All of this sound good and fine ,However I suspect this is going to be a place were mE can place some special developed Libraries
for the use of the users however at a Price it will be Libraries seen by mE as not part of the compilers and therefore the user have to pay for them .!!

This Libstock is not there for the benifit of the mE compiler soley as we are made to believe !! I am not so optomistic anymore regarding Libstock ,this became clear when I read the post that FAT32 Lib will not be part of the compilers !!

I have answered to this on the Library Developer's Discussion Forum, but I will repeat my answer for the sake of others.

We will not sell FAT32 at Libstock. It will be shared and maintained there for free.
The main reason for this is that with FAT32 placed on Libstock, rather than in compiler itself,
we won't have to pursue 100% backward compatibility with existing FAT libraries at all costs.

So, compilers will retain the original backward compatible libraries,
and we will separately maintain part of the libraries on Libstock on regular basis.

This also releases the tension of having strict rules for compiler releases,
and our developers can even write libraries in their spear time, and share them
with the rest of the community. I, for myself, have already several libraries
I want to share, which would otherwise never get in the official compiler release.

Don't worry, I assure you it is not our intention to do any harm, but quite the opposite.

Eventually, some libraries can be included in the compilers directly,
but maintaining them on Libstock will bring much frequent updates of the libraries,
and you won't have to wait for the new compiler releases to get some new functionality.


Best regards,
Aleksandar