Suggestion about pub module
Monkey Forums/Monkey Programming/Suggestion about pub module
| ||
| Earlier (about 1.5 years ago), I have already raised this question. Then it did not work out. Maybe now something will change. I suggest to create a large group of modules - "Pub". Similar to what we have now from Blitz Research (brl) and what was in BlitzMax. The purpose of these modules - to extend the basic Monkey functional. To allow users to connect only one module and get access to all the advanced functional. What does this module may contain? Well, for example - Various parsers, i.e.xml, json, csv, etc. - Module for working with regular expressions - Module for working with database - Module with additional streams. For example, zipstream And other common modules like md5, base64, etc. As you can see, these are the often-used and common modules. They almost aren't attached to the platforms, so some of them can be written in pure Monkey and will work on all targets. Pub module will not contain game frameworks, modules that are tied to the advertising network, or use various web services. I know that a lot of this is already exists in various individual modules from different authors. But I don't find it comfortable. Pub module won’t have a single author. Each person can connect to the development or offer his module. The decision on the inclusion this or that module will be made by community, by voting. Thereby we can unite our efforts in order to create more interesting and useful modules. All modules will be distributed as a Public Domain. Pub module will have it’s own public page on GitHub or Bitbucket, where the repositories with modules will be stored. Due to this code will always be available for download. And also there will be a version control. Pub module will have strict naming. For example pub.parser.xml or pub.stream.zip etc. Or something like that. It is necessary to discuss. Also, all modules will be documented, just like standard Monkey modules are documented. All modules will be very simple and will provide only basic functional. This does not restrict others to create alternative modules. Also, it won’t be one big module. It will be a lot of small modules gathered in one place. This is how I see it. I would like to know your opinion. What do you think about this? Does anyone would like to participate in this or you ready to insert your own module in to the pub? Which modules would you like to see here? Any suggestions are welcomed |
| ||
| I'm all for it! |
| ||
| Good idea. The strict naming convention is also a good idea, maybe even we could do it that similar modules function in a very similar way (e.g. xml and json parsers having an interface). |
| ||
| Having looked back at that thread (http://www.monkeycoder.co.nz/Community/posts.php?topic=1191) I can't say that my position has changed. Restating it a little: I see the problems with module discoverability but I don't think that creating a big shared workspace is a good solution. There's nothing wrong with creating a collection of useful modules if you want (I'm sure the diddy guys would agree that diddy itself is really such a grab-bag of handy libraries more than a framework) but I don't see that it solves the underlying issue, which is that people can't find the modules they are looking for. To solve that someone needs to look at why the module registry fails. |
| ||
| @Shinkiro1 I like the idea of a single interface for similar modules! I think it will be possible to discuss the modules schemes, if we decide to implement it. @muddy_shoes Unfortunately, time passed, and the issue only became worse. We still need some basic modules, which we would like to have. And those that we already have are sometimes hard to find. Newbies often ask me: “How do I read xml?” I say - "Use diddy", but they are already using fantomEngine. And I have to explain that you don’t need to import the entire module and it isn’t necessary to use diddy as a framework to read xml. This is very confusing ... I can create another module like diddy. And call it devolonter, for example. But will it tell anyone that there are libraries that read various formats and many more useful things? I suggest to make Pub module - as the unofficial standard module for Monkey. A small basic modules register, if you wish. It will be easy to search in it, and good documentation will be helpful for newbies. Why a lot of separate submodules instead of one? In order that each module has its own repository, and everyone could do its fork. Also, to be able to get different versions for each module separately. But everything should be under one roof in order to follow the same standard and to be in one place. I think it wouldn’t be a huge bunch. In fact, it will be good if there are at least 10 modules. I suggest to do only what is really necessary in almost all applications. |
| ||
| But the exact same problems that exist with diddy will exist with your "pub" module collection. It's just a different bag of stuff to look in and understand. Yours might be easier to comprehend as a utility collection, better documented, structured etc. but it's still the same thing. Again, I'm not against anyone creating a module collection. If you want to do that, then fine. If you want to include my box2d, json or whatever modules then you're very welcome to do so. It's just not an approach that I see as particularly productive. The thing is that we supposedly have a central module register that, in principle, resolves the exact problems you're talking about. In practice it's a minimal effort implementation that is unloved and unused. I really think that BRL should step up and resolve those problems but I'd certainly be interested in discussing a "better register" as something separate from your module collection idea. |
| ||
| I have to disagree with devolonter. The joy of monkey is the really good level of modularity it has. Import the whole diddy framework just to read XML? Why not? only the required bits will be included in the compiled process,as Monkey discards automatically unused code. That said, the more choices we have, the best. I was trying to find a good XML parser the other day, tested a couple of them and finally decided that the best for my needs was the one by skn3 in the modules registry page. It works very well. It would't work any better if it was "official". |
| ||
| I think there is some functionality that is used so often it makes sense to have just 1 solution. Think of a 2D Vector. I recently released my particle engine Pato and of course renamed the vector class to PatoVector so I don't come in naming conflicts with the users classes. Ziggy, don't you have a GuiVector in jungleGui as well? So using just 2 libs this fragmentation causes the user to have 3 different vector classes which essentially are doing the exact same thing. |
| ||
| Yes, there's a 2D vector class on Jungle Gui, and 2 of them in the game I'm writing. Maybe a very simple vector class could be officially added. If this ever happens, I would love to have immutable types, and a 1965 Fender Stratocaster too. Now seriously, a simple 2D vector is not really a functional complex implementation like an XML parser. I agree that some very basic classes could be added to Mojo or to the language itself. That said, I don't see the benefits of a centralized framework of modules that are not a framework. I think it would be much much better to have a proper way to publish open source modules here, and allow users to rate them and state the compatibility level with latest official Monkey release. Sort of what they do with wordpress plugins. But I don't know if the complexity of this development is worth it given the small comunity we are (yet?). |
| ||
| I like the idea of having a community based pub collection but I strongly dislike the include once approach. Sometimes you just want something simple to import. It could be good if there were a lot of contributers. Some people could code, and others who maybe didn't have time to develop could document and write simple examples. It would require someone with a lot of spare time to administer. Anyone up for the task? Btw I would be happy for the xml module I wrote to be a part of it. |
| ||
| @ziggy: I was trying to find a good XML parser the other day, tested a couple of them and finally decided that the best for my needs was the one by skn3 in the modules registry page. It works very well. It would't work any better if it was "official". Any particular reason you chose skn3's? If there's something you don't like about the Diddy parser, I can work on it. :) |
| ||
| @Samah: I tried the one on the config demo and skn3 one but not yours. |
| ||
| Tbh a module idea is a good one but I would like to see something built into the ide so we can import source from a central BRL repository into our projects. With a central repository mark or so can ratify the source code to make sure it does what it should and when someone wants something in their project they can search the repository using the idea tool for code and import one they want. I might actually have a look at doing something like it myself :-) |
| ||
| Ziggy, from my own experience I can say that it confuses a lot of people. Moreover, the perspective of searching and downloading numerous modules in order to just start writing an app really demotivates. I note that I am not against the alternative. If a module provides the ability to read xml along with the framework - this is great! If there is a faster implementation - this is great too! But I think it would be also good to have the opportunity to get extended functions with one click, not being tied to a particular framework. Yes, maybe it won’t be the best choice or not the best implementation, but it's just what might help to quickly start writing code. As if it was bootstrap. Let me repeat once again. Modules will contain only basic functionality. There will be no super-duper huge modules with dozens of dependencies. In an ideal, one module - one purpose. I also agree with the fact that there is a problem with the current module registry. And pub module will not resolve this problem. It would be great to have a module registry with categories, tags, rating and compatibility information. When I’ll start to do module's page design I can provide how I see it. There, we could also discuss it. Even if BRL refuses to implement it - we can do it on our own. Also it would be good to have some command-line utility for importing modules with all dependencies. This could be done based on the module registry. Thank you muddy_shoes and Skn3 for your consent to the inclusion of modules! Now we have something to begin with. And we need to think about the best way to use it. I originally did not plan to make code review and bring everything to a single structure. Only strict naming convention and good documentation were in the plans. I don’t want to complicate everything, because I think it's better to spend energy on writing new modules. But if you think that it is not very good, then we can discuss the schemes of module interfaces. As for the administration. I’ve created (renamed and cleaned former MonkeyModules) organization on GitHub - https://github.com/pub-monkey Here I plan to keep all repositories, as well as to have a discussion. Also in the main repository there will be wiki with information for contributors and users. In the future, we can make a small site with more information. I may include anyone who wishes as contributor. I also think that it need to be added another 1-2 administrators to avoid losing access to the control panel, if one of us wants to leave. Skn3, Shinkiro1 I know that you have accounts on GitHub. Would you like to join this organization? I can send you an invitation. Important! I do not insist on GitHib. And if you have objections please let me know. I also think that the pub-monkey may not be the best name, so I’m ready to change it. But I think the name is not so important, eventually. As soon as we’ll figure out all the organizational issues, I suggest to go over to making naming convention and preparing roadmap. |
| ||
| maybe fur, instead of pub? Or is that even more confusing haha I do feel this is a good idea. I feel like I have re-created way to many color classes, screen-switch classes, resource managers, autofit / resolution code, cameras, transform/matrix, log class, parsing, and so on... The Vector class I did (and posted on the forum) is probably the only class I'm still using without changes, feel free to include if you want. The other opportunity of improvement that we as a community have is that people seem to re-write a lot of code is something I'd love to see a solution to. I'd vote for bitbucket & mercurial, but I'm OK with Git too. |
| ||
| I just want to clarify that I meant that I'm happy for you to include my modules in a collection but not that I will move them into a shared repository. The value in having a single download for users to get a bunch of useful modules doesn't follow through to meaning that there's any sense in actually working on those modules in the same space. Glad to hear that you're willing to look at improving the module registry. I really think that moving it forward towards something like ruby's gems is the way to go. |
| ||
| Git would be fine for me. |
| ||
| I like the idea... I have some modules I can share with you... Just let me know if you're interested in any of the modules on my google code page. The link is in my sig below. |
| ||
| Hey Dev, Git would be good! I have moved over to bit bucket recently, simply to save money on private repos. But yeah, add me to the repo :D Maybe the repo could be split it into a few branches of dev? E.g. pub.core pub.extra core could contain stuff like xml, vector, encryption. extra could contain anything else that is deemed widely usable but not considered "core" With regard to naming convention I think it would be good to adopt some guidelines but not be too strict. But saying that, everything in monkey is very verbal and minimalist so it would be good to stay on that convention. eg List instead of IList/PimpList/CoolFrameworkList eg Map instead of IMap/PimpMap/CoolFrameworkMap I don't know about anyone else but I like our new verbal overlords and I welcome them! It makes for nice clean code. Local list:= CreateList() vs Local list:SuperDuperPubRepoList = CreateSuperDuperPubRepoList() Easy decision :) |
| ||
| All file parsers could be grouped together: files.json files.xml files.css They could all share a common api so a user that gets 1 of them can understand the rest easily. Same goes for other modules. As for coding standards - I guess we can adapt the monkey ones and such things as Skn3 mentioned can be left to the developer (internal stuff). |
| ||
| Tibit, thank you! Maybe fur, instead of pub? Or is that even more confusing haha Maybe bootstrap? :) I really don’t know. Any suggestions are welcomed muddy_shoes, yes, of course, I understand that. Thank you again! wiebow, thank you! I think we can include some of your modules to the collection. I'll let you know which particular, a little bit later It looks like we continue to use git and GitHub. OK, one thing is decided. Skn3, Shinkiro1 I sent you invites. I hope, so we can more quickly coordinate the work. About the division. I like the idea about pub.core and pub.extra. Also, I like Shinkiro1’s approach with files.json, files.xml I think that the reasonable structure would be pub.core.files.xml etc. How do you think? As for the brunch. I think it would be better to use different repositories for different modules. For example: The main repository will be "pub". It will contain all modules in the core and extra folders as links to other repositories (submodules). As well as utilities for building documentation. Also in the issue-tracker of this repository will be discussed the main issues of the collection: roadmap, modules offers, etc. The rest of the repositories may have the same name as in import. For example, "pub.core.files.xml" - in this repository there are the source code for reading xml. Also, I think, there would be repositories of "pub.core.files" type which would contain the common interfaces and links to the repositories. But probably this level is already unnecessary. What do you think? Perhaps it’s too confusing, but I think by having a lot of repositories, we can have a better control version of each module. So that users can conveniently download the latest version and find out collection features I can quickly prepare the website on bootstrap and post it on GitHub at http://pub-monkey.github.com/pub/ Also we need a downloads repository, because GitHub removed downloads page: ( |
| ||
| To combine the two suggestions then Id say that it would be good to simplify it further: pub.core pub.files pub.graphics pub.etc... pub.core.arraylist pub.files.xml pub.graphics.render2texture (or replace pub with whatever name it chosen) I am sure it will be easy enough to make general categories with just one folder depth? What about "leaf" ? leaf.core , leaf.files, leaf.graphics I am not sure I agree with conforming things like all parsers should use the same API? It could deter people from adding to the pub if they have to restrict to the api? I think that it would be good to refrain from treating it like a framework and more as the pub folder; a collection of essential individual modules with minimal dependencies. To illustrate the point, I already spent a good while making an XML module so teh thought having to rewrite/rework it is not as appealing as "hey here you go you are free to include this in pub" PS: I like the idea that each module is a link to a different repo. Means I can continue pushing to my own modules directory :D PS2: I can't see an invite? |
| ||
| I have no objection against one folder depth. I think this will be quite enough. I am not sure I agree with conforming things like all parsers should use the same API? I agree that the same API will complicate the inclusion of already existing modules. I believe that to have a single API is good, but it will be unnecessary. In the future, I think we can somehow improve it PS: I like the idea that each module is a link to a different repo. Means I can continue pushing to my own modules directory: D Excellent! If it is comfortable, you can continue development at your side. I do not want to force developers to change their comfortable surroundings. Something will be developed within the pub, something will be just copied. I can't see an invite? I think I’ve used the incorrect term :) I’ve connected you to the organization. You can see yourself here https://github.com/pub-monkey?tab=members Also link to the organization is available on the home page of your profile (at bottom left corner). Now, when you will create new repository, you can select pub-monkey as the owner |
| ||
| Huzzah ok I see myself now :D Is it possible to external link to a repo hosted elsewhere? I currently have the most uptodate xml module on bitbucket. It would be good if the pub git repo could do its linkage, but to bitbucket? If not, I could always setup a "service" on bitbucket and then fire off message to a webserver to trigger a sync from bitbucket -> github. |
| ||
There is no problem with adding git-repositories from other sites. To add the repository as a submodule from bitbucket you need to execute:git submodule add git@... Unfortunately, you can’t add one or more folder from repository. Only the entire repository |
| ||
| Hello, I'm usually against standard library things like this, unless they are demonstrably "the best" at providing what simple functionality is necessary for them in terms of efficiency and extendability. For example, vectors in particular are perhaps one of the things I think you'd want to have all sorts of features and easy access to the methods inside, but at the same time, an overly object-oriented approach to designing a vector class could be bad for the gc on some targets. (I made this mistake myself when rolling my own 2d vector class early on) I side mostly with the posters who see Monkey's modularity as one of its strengths, and a core philosophy trending towards minimalism. If this is going to be a thing, it needs to be a cut above the other frameworks available for Monkey. Every module in it has to be its best-in-class; something that would preclude anyone wanting to create their own for any purpose other than to extend the functionality of what is provided. |
| ||
| By the way, I have a few modules which may be helpful to this project, but I'm not sure the code is up to those high standards I laid out in my post above. (Stuff like not being 100% consistent when it comes to things like naming non-properties like locals in CamelCase, and using Hungarian notation occasionally -- vestiges of old VB6 habits). Let me know if anyone's interested in any of these, or if there is no work being done in these areas, as I've written my own modules for them: * AutoScale (automatic matrix-based screen scaling and translating to center to fit device dimensions based on a virtual screen size, with optional region-scissored letterboxing) * Extra draw routines: Rounded rect (filled or empty), Multiline DrawText, monospace word-wrap, etc. * A very simple texture atlas loader which can return grabbed images and doesn't require calling its own draw routine to work There's also some more complicated stuff that is probably beyond the scope of this module: * Screen transition class * Non-diddy-based screen and overlay interface (including return value and modality support) * bare-bones widget base with input dependencies abstracted away to a separate InputPointer class All of these modules can run without any dependency on any of the others, so they don't really consist of a framework, but the simpler ones may be applicable to this thing because of their applicability, if better ones don't already exist... |
| ||
| Nobuyuki, thank you for your suggestion. I think in the near future, we will determine what modules will be added to the collection, and let you know. Well, we have a last question to be solved before we move development to GitHub. What name shall we choose for our collection? My suggestions are pub, bootstrap, elements. Maybe you have a better name? |
| ||
| Nooooo GitHub noooooooooooooooooooooooo........... I've been forced to use it for one project and it's been like pulling teeth. D: |
| ||
| Nooooo GitHub noooooooooooooooooooooooo........... As always, I get the chance to mention how wonderful and nice working with Mercurial is. |
| ||
| hg +1 |
| ||
| Hg +1000 Disclaimer: I'm not bashing Git because I don't want to start a holy war. It seems very powerful and from what I've read, pretty much feature-for-feature with Mercurial. But: a) I don't want to learn another tool (selfish, I know) b) I find BitBucket to be a bit easier to use than GitHub (comparing online repository hosts, not the tools themselves). c) TortoiseHg is amazing; TortoiseGit and most other Git GUIs I've seen are not. Knowing all the commands is great for people who love CLIs (and are generally very good at using them), but for those of us who would rather click, a decent GUI will improve workflow by many magnitudes. Actually, the only decent Git GUI I've seen is SourceTree (also does Hg), but that's Mac only, and commercial software. |
| ||
| +1 to Hg |
| ||
| Guys, please, let's not start a holy war. When I asked, no one was against git and GitHub. Now I don't see any reason to return to this question. Samah, about your arguments: a) Unfortunately, I'm not familiar with hg and I have no opportunity to learn it right now b) It is a matter of taste. I find BitBucket less easy c) GitHub has recently released a client for Windows. This program is very easy to use. Besides it is integrated with the GitHub API and works fine with all git repositories (including BitBucket) Ultimately, users won't need to know git. We will prepare a page where we will place stable version for download. |
| ||
| Guys, please, let's not start a holy war. Which is why I said I didn't want to start a holy war. a) Unfortunately, I'm not familiar with hg and I have no opportunity to learn it right now Fair enough, although I think Git -> Hg will be easier than Hg -> Git. b) It is a matter of taste. I find BitBucket less easy Also fair enough. c) GitHub has recently released a client for Windows. This program is very easy to use. How recently is recently? I remember trying their Windows client and found it quite awful. Ultimately, users won’t need to know git. We will prepare a page where we will place stable version for download. How many developers will there be? If it's easy for me to contribute and/or fork+pull request, I will. Mind you, last time I made an awesome improvement to a project, my pull request got rejected due to "upcoming changes" which never happened, and the project became somewhat stale. |
| ||
| Oh also, I used to be against Git too, because of the seeming lack of nice tools to work with, but consider me a convert after spending a few hours with Git Extensions -- sometimes a nice UI to get you up and running with the basic stuf is all that's needed to make working with another system palatable :) +1 to BitBucket, though. It's been good to me so far. And it has a decent wiki system, too, in case (god-forbid) any of you guys want to DOCUMENT your work on this project! (It has Monkey syntax-highlighting support, too, apparently) Edit: Need more lib name suggestions? How about... "More"? :D |
| ||
| I'll use Git when I find it fun to use. At the moment I find Mercurial fun, and Git just looked like a headache. Show me how to make it fun and I'm all for it. |
| ||
| Samah: If you don't have git on your system already, get the full package from Git-extensions, which will include the dev version of Git, KDiff3, and the Git Extensions gui. Then maybe check some of this out for how to use it (it's got pictures, explanations, and some youtube links): http://gitextensions.googlecode.com/files/Git%20Extensions%20-%20User%20Manual.pdf And if you don't know the system behind Git and why it could be exciting for you as a coder, one of my friends recommended this, which I read a little bit of and it helped me grok the concepts quite a bit (and also why once it's easily understood, how it makes all previous repo systems pretty much obsolete): http://www-cs-students.stanford.edu/~blynn/gitmagic/ Edit: found another link with more on how to setup Git-Extensions... http://www.codetunnel.com/blog/post/106/installing-git-on-windows |
| ||
| Thanks Nobuyuki, I'll check it out when I get a chance. I already have both TortoiseGit and the official GUI client installed and I don't like either of them. :( Back on topic: I'm happy to help if you can give a more extensive list of libraries you're interested in including. |
| ||
| Tbh all this screams for a separate code archives on this site like the blitz basic.com one, seeing as monkey is a desperate beastie in the coding sense then maybe that's the option. |
| ||
| Git and hg both solve problems a plain code archive has especially with many contributers. As for which of the 2 we go, I think we should choose one and then stick to that. Yeah, some things may be better in the 1, and person X dislikes feature Y but in the end we just want to share code and not use a version control system for the sake of using it? Unquestionably both are up to the task. @Samah: So you did test this one: http://windows.github.com ? I don't know about the Windows version but I use the Mac one all the time and it works great (again, just preference maybe) |
| ||
| In all honesty a plain code archive is something that monkey needs not over complicating everything with git and mercurial and the code archives have served blitz well over the years. However i do agree that the code archives does need moderation as some of the things on there are either dead links or crap tbh |
| ||
| How recently is recently? I don't remember exactly. Perhaps first versions were unstable, but everything is much better now. But it's also a matter of taste I prefer GitHub for several reasons: 1. This is their main business, while Atlassian's Bitbucket is only a by-product 2. It is developing rapidly. Bitbucket was simply awful until recently. Although the last big update made it better 3. A more convenient way to host your own web-pages, which I use quite often Although I also have an account on Bitbucket and I find some things, such as the import of repositories very convenient. In general, Bitbucket service is good, but GitHub is more preferred for me. Shinkiro1 is absolutely right. You can continue to use your control version system and service that you prefer. This collection will just gather everything useful in one place. Yes, some modules can be developed in it. But it's not necessary. Samah, I'm glad to hear it. We need to make a decision about the name and then we can make a list of modules. Nobuyuki, "more" sounds good! Any other suggestions? EdzUp[GD], git and mercurial are only for module developers. For other Monkey devs this collection will be only as one link for the archive with all useful basic modules |
| ||
| For anyone else not really into git, take a look at the smartgit client. http://www.syntevo.com/smartgithg/index.html Its totally free to use for nonproffit and probably the nicest version control client I have found. Just the right amount of power and ease-of-use. I have used command line, bash (erm batch) scripts, tortoiseGit, github client and SmartGit. SmartGit gets my vote! Naming.... I think to be honest "pub" is nice. Its self explanatory, at least in English. I did some reading up trying to see if there was any way to sync a folder as a sub module. Unfortunately not doable. My best option would be to either reorganise my modules repo to link to submodules one for each (not very appealing) or just setup some kind of automated syncing mechanism to a separate repo. I'll probably have a play at some point to get this working. |
| ||
| I did some reading up trying to see if there was any way to sync a folder as a sub module. Unfortunately not doable. My best option would be to either reorganise my modules repo to link to submodules one for each (not very appealing) or just setup some kind of automated syncing mechanism to a separate repo. I'll probably have a play at some point to get this working. I think transcc should allow a parameter that allows us to specify an additional modules folder. This way we could have the compiler modules folder that comes with the official release AND another folder that could be shared on all Monkey updates and versions, making the updates a bit less painful. That would be a lot easier that playing with junctions, or similiar NTFS black magic |
| ||
| That would be a lot easier that playing with junctions, or similiar NTFS black magic ... and inadvertently causing headaches for certain Jungle Developers.. ;) +1 for custom module folder |
| ||
| and inadvertently causing headaches for certain Jungle Developers.. ;) Yes, it was painful! try to get some low level information on the .net MSDN forums... (just for people that's not aware of what are we talking, this is related to a small bug Jungle Ide had with computers having symlink folders on NTFS drives and cross-reference of the same file with different paths on the same jungle session). It's solved in current dev version. |
| ||
| +1 for custom module folder You mean like the MODULE_PATH config variable I added to monkey-ext last year, and that Mark only recently included? |
| ||
| What's MODULE_PATH? If you mean modpath parameter, I think it is replacing current module path with a custom one. I mean adding (not overriding) a module path to current default one, so you can get the monkey built in modules and mojo updated without having to copy all the other modules every time. It's too easy to get different versions of the same modules spread on the system if you're the kind of mess I am and it looke like an ultra easy addition to trans. |
| ||
| The ability to add custom import directories is a feature that has been requested multiple times. If BRL had a proper feature request tracking solution I'm sure we'd have it by now. |
| ||
| In config file of Monkey V67 I've noticed the following: MODPATH="${MONKEYDIR}/modules" Is this what you need? As for naming, I also prefer "pub" |
| ||
| Multiple additional module paths is what's needed. Can MOUDLE_PATH do this :o? |
| ||
| No. It's not. Sorry! EDIT: MOD_PATH is just set to point to the regular module's path (or whatever you override when using the command line to compile). What I think would be a super improvement would be to allow users (and IDEs) to provide an additional module folder that can be stored anywhere, so you can keep, let's say, a third party modules folder in your system and share it with all Monkey versions, so you update easier, taking into account monkey is updated "early and often". |
| ||
| Definitely! I would be greatful of this. It's always a pain having to symbolic link everything up! |
| ||
| This link has been posted a few times on this forum, but I really should have it in my signature. http://code.google.com/p/monkey-ext/ This is at the end of my config.winnt.txt: '-------------------- ' Module Path ' Provides additional search directories when importing modules. Semicolon separated. MODULE_PATH="D:\Users\WoolcockS\Dropbox\Repositories\DiddyHg\src" MODULE_PATH="D:\Users\WoolcockS\Dropbox\Repositories\modules" MODULE_PATH="F:\Dropbox\Repositories\DiddyHg\src" MODULE_PATH="F:\Dropbox\Repositories\modules" That way it caters for Dropbox at home and at work, and it allows me to keep Mojo separate from Diddy. The MODULE_PATH stuff in monkey-ext is only compatible with v66b, since it's (possibly?) unnecessary in v67. I have a separate v67 branch on my local clone but I'm waiting for Mark to make v67 official before I push it. Edit: Clone and update to the latest development branch, then modify config.winnt.txt (or whichever platform) as you need. |
| ||
| > In config file of Monkey V67 I've noticed the following: MODPATH="${MONKEYDIR}/modules" Is this what you need? This should work although all module dirs have to be on one line (I think), eg: MODPATH="${MONKEYDIR}/modules;${SYSTEMDRIVE}/modules_ext" Note: Internally, this is prefixed with current dir and main source dir, and suffixed with target modules dir. |
| ||
| The ability to add custom import directories is a feature that has been requested multiple times. If BRL had a proper feature request tracking solution I'm sure we'd have it by now. You're welcome to use the issue tracker on the monkey-ext project, then anyone is free to make language changes and submit pull requests. If there's something people want that Mark hasn't added (or won't), I'm sure someone in the community is happy to do it. Clone monkey-ext, make your changes, and make a pull request. Just remember not to commit Mojo. I take no responsibility for any content outside the official monkey-ext repository. |
| ||
| I'm aware of the capability to create/use feature request tracking systems in general. If I weren't then I wouldn't be able to point out that BRL doesn't have one. That you or me or anyone else has one doesn't address that lack either. Unless BRL has explicitly undertaken to track and pull changes from monkey-ext I don't see that it's a solution to start putting requests there when the desire is to have them in the core product. |
| ||
| I'm aware of the capability to create/use feature request tracking systems in general. If I weren't then I wouldn't be able to point out that BRL doesn't have one. Where did I say you weren't? o_O I was just pointing out that if you're interested in having it added to monkey-ext, that's where you can submit it... Unless BRL has explicitly undertaken to track and pull changes from monkey-ext I don't see that it's a solution to start putting requests there when the desire is to have them in the core product. If Mark doesn't want to add certain things (I don't know why there isn't a feature request subforum) that's his decision. In that case, you have no choice but to request your desired feature as a third-party addon. Thankfully Monkey is public domain, so we can do as we like. |
| ||
| Samah, my point is that your response to me doesn't actually address the issue I raised. I didn't refer to monkey-ext so colour me just as confused as to why you told me that your project has an issue-tracker as you are about my response attempting to make some sense of your motive. There are many fine community projects and I'm sure monkey-ext is one of them, but the idea that expectations/requests of the core product can be deflected onto them isn't reasonable. If BRL were actively curating, supporting and tracking those projects, maybe, but that's not the case. |
| ||
| ...but the idea that expectations/requests of the core product can be deflected onto them isn't reasonable. Which is why (since Monkey is supposedly public domain) it should really have an official source repository here so that people could fork without having to start their own standalone projects. That way BRL could be the one accepting pull requests. Let's agree that Mark needs to provide an easier method for his community to give back. It's easy enough for him to take snapshots of the master branch, add Mojo, then upload them as MonkeyPro<insert_number_here>.zip to the product updates section. |
| ||
| I absolutely agree with that idea: http://www.monkeycoder.co.nz/Community/posts.php?topic=607 |
| ||
| It could be nice to have a public repo although really it is whatever the developer (Mark) is comfortable with. Probably outside of the scope of this topic though? How can we move forward with the pub plans? Dev? |
| ||
| I would also like to see an official public Monkey repository. With issue-tracker and the ability to send pull-requests. And also in order to have the ability to see versions diffs. It would be very useful. Although there are several unofficial repositories now and it helps a lot, but ultimately I would like to get it officially. As for the pub module. I was waiting for more suggestions for naming, etc. But it seems that we may already continue. OK, the name remains the same - pub. I’ve just created the main repository. I suggest to hold all discussions there, in issue-tracker. Once we define a set of modules and structure we may start to add the source code. Also feel free to write your comments and suggestions for discussion. If you have any suggestions, but you aren’t registered on GitHub please write them here. We will certainly take them into account. |
| ||
| Regarding the XML parser, if you want I can take the Diddy one, strip out all other Diddy dependencies, and rename/format to whichever coding style is decided. Edit: Posted on issue tracker. |
| ||
| As much as I love the XML parser in Diddy, it would be wise to compare all of the ones out there to see which one is the "best" and improve on it... also maybe using a common XML base and use native code might be better. |
| ||
| I can't find the Git-link to this module? Am I in the wrong thread? I saw some discussions in the issue tracker on Git but forgot to bookmark it. |
| ||
| You can find repository of this modules bundle here - https://github.com/pub-monkey/pub (see develop branch) |
| ||
| Thanks! |
   |