Re: [Gambas-user] Gambas Software Farm in revision #6676
I for one would be in favor of a "published" and "private" access to components available on the farm. RegardsMike On Wednesday, 26 November 2014, 13:25, Kevin Fishburne wrote: On 11/26/2014 12:02 AM, T Lee Davidson wrote: > On 11/25/2014 10:38 PM, Kevin Fishburne wrote: >> Since the farm (as it stands currently) is only for free software (as in >> GPL), users will be free to circumvent payment by downloading the >> application from another source, such as someone who paid and then began >> hosting the source code and/or binaries themselves. This is perfectly >> legal, as the GPL states users may modify or distribute the application >> as they see fit as long as they provide access to the source code. So >> payment will effectively be for convenience, application support or >> kindness rather than the only way they can access the application. >> >> I'm thinking that creating a payment system for GAMBAS would be an >> insane amount of work and probably isn't a good idea. A much easier way >> would be to support existing payment solutions such as PayPal. Here's >> some information on their "digital goods" payment solutions: > Benoît stated that the Farm was not intended to be a marketplace. While that is true, it may not always be the case. Things change according to the wants and needs of users and developers. At this time there may be little interest in that particular functionality among developers, but it seems an obvious extension to what is essentially a digital distribution service, so I think it's worth at least discussing. > Hence, my suggestion that it could be used as a pseudo-marketplace by > allowing publishers to make their listing private. The payment and/or > transaction details, access credential delivery, and level of on-going > support (free/paid) would be the responsibility the individual publisher. That's an interesting suggestion, but I'm not sure if it can be made to fit in with the plan to have the farm compile and install the application on the end user's system. If that's the farm's primary objective then it would be too late for a password-protective archive as the program would already be installed. > I was not suggesting creating a payment system for GAMBAS, nor > complicating or burdening the Farm platform with transactional needs. I am suggesting 3rd party payment processing integration. :) Didn't mean to imply that you were suggesting it. > Any publishers successfully using the Farm commercially could graciously > 'buy Benoît a beer', or three. True, I've even bought him a few beers myself, but I wouldn't build a business on that premise. -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sa...@eightvirtues.com phone: (770) 853-6271 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
On 11/26/2014 12:02 AM, T Lee Davidson wrote: > On 11/25/2014 10:38 PM, Kevin Fishburne wrote: >> Since the farm (as it stands currently) is only for free software (as in >> GPL), users will be free to circumvent payment by downloading the >> application from another source, such as someone who paid and then began >> hosting the source code and/or binaries themselves. This is perfectly >> legal, as the GPL states users may modify or distribute the application >> as they see fit as long as they provide access to the source code. So >> payment will effectively be for convenience, application support or >> kindness rather than the only way they can access the application. >> >> I'm thinking that creating a payment system for GAMBAS would be an >> insane amount of work and probably isn't a good idea. A much easier way >> would be to support existing payment solutions such as PayPal. Here's >> some information on their "digital goods" payment solutions: > Benoît stated that the Farm was not intended to be a marketplace. While that is true, it may not always be the case. Things change according to the wants and needs of users and developers. At this time there may be little interest in that particular functionality among developers, but it seems an obvious extension to what is essentially a digital distribution service, so I think it's worth at least discussing. > Hence, my suggestion that it could be used as a pseudo-marketplace by > allowing publishers to make their listing private. The payment and/or > transaction details, access credential delivery, and level of on-going > support (free/paid) would be the responsibility the individual publisher. That's an interesting suggestion, but I'm not sure if it can be made to fit in with the plan to have the farm compile and install the application on the end user's system. If that's the farm's primary objective then it would be too late for a password-protective archive as the program would already be installed. > I was not suggesting creating a payment system for GAMBAS, nor > complicating or burdening the Farm platform with transactional needs. I am suggesting 3rd party payment processing integration. :) Didn't mean to imply that you were suggesting it. > Any publishers successfully using the Farm commercially could graciously > 'buy Benoît a beer', or three. True, I've even bought him a few beers myself, but I wouldn't build a business on that premise. -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sa...@eightvirtues.com phone: (770) 853-6271 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
On 11/25/2014 10:38 PM, Kevin Fishburne wrote: > Since the farm (as it stands currently) is only for free software (as in > GPL), users will be free to circumvent payment by downloading the > application from another source, such as someone who paid and then began > hosting the source code and/or binaries themselves. This is perfectly > legal, as the GPL states users may modify or distribute the application > as they see fit as long as they provide access to the source code. So > payment will effectively be for convenience, application support or > kindness rather than the only way they can access the application. > > I'm thinking that creating a payment system for GAMBAS would be an > insane amount of work and probably isn't a good idea. A much easier way > would be to support existing payment solutions such as PayPal. Here's > some information on their "digital goods" payment solutions: Benoît stated that the Farm was not intended to be a marketplace. Hence, my suggestion that it could be used as a pseudo-marketplace by allowing publishers to make their listing private. The payment and/or transaction details, access credential delivery, and level of on-going support (free/paid) would be the responsibility the individual publisher. I was not suggesting creating a payment system for GAMBAS, nor complicating or burdening the Farm platform with transactional needs. All I was proposing was simply allowing publishers to make their listing private if they wished. The rest would be up to them. Any publishers successfully using the Farm commercially could graciously 'buy Benoît a beer', or three. -- Lee __ "Artificial Intelligence is no match for natural stupidity." -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
On 11/25/2014 07:07 PM, T Lee Davidson wrote: > On 11/25/2014 05:25 PM, Benoît Minisini wrote: >>> Now, for those who may wish to use the Farm as a >>> (pseudo-)marketplace. I wonder if adding the ability to >>> password-protect an application/component listing, like "published" >>> and "private", would be worth considering. It would definitely not be >>> ideal, but might be workable. >>> >> Please elaborate. > I don't know if I can elaborate much as it was just a conceptual idea. > Wordpress allows pages/posts to be published as public or private. It is > a similar concept but applied instead to application/component listings > on the Farm. > > Conceptually, publishers could choose to password-protect their listing. > It may be visible, with its description, in whatever directory or > listing there is, or found through a search. But, to view the source > code or to download/install the program would require a password that > the user would need to get from the publisher. > > One of the reasons it is not ideal is that passwords can be easily > shared. A publisher might, therefore, wish to periodically change the > password for their listing. > > Again, not ideal, but maybe workable. For a true marketplace, specially > coded (redirect) download links would likely be generated on-the-fly > after payment processing. > Since the farm (as it stands currently) is only for free software (as in GPL), users will be free to circumvent payment by downloading the application from another source, such as someone who paid and then began hosting the source code and/or binaries themselves. This is perfectly legal, as the GPL states users may modify or distribute the application as they see fit as long as they provide access to the source code. So payment will effectively be for convenience, application support or kindness rather than the only way they can access the application. I'm thinking that creating a payment system for GAMBAS would be an insane amount of work and probably isn't a good idea. A much easier way would be to support existing payment solutions such as PayPal. Here's some information on their "digital goods" payment solutions: https://www.paypal.com/webapps/mpp/digital-goods https://cms.paypal.com/cms_content/US/en_US/files/merchant/paypal_digital_goods-express_checkout_getting_started.pdf "Express Checkout" supports NVP and SOAP while "Adaptive Payments" (not sure what the difference is) support those and JSON. Adaptive Payments also supports multi-party payments, meaning Benoît can have his 10%. =) When submitting an application to the farm it would need to give you the option to enter a PayPal merchant ID and a sale price. When someone chooses to download that project, the farm would use PayPal's mechanism in conjunction with that information. When the purchase is successful, I'm guessing PayPal would communicate back the payment status, after which the Farm would download/install the application. I think all of this is web-based, perhaps someone else has more experience with this? -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sa...@eightvirtues.com phone: (770) 853-6271 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Problem with Process_Read
I did more testing with latest revision (6679).
I made pure command-line version of the tester and I do not get the crash.
However I get random failing of the test. Sometimes the string is not
returned, instead null string.
The project is attached. Test 239 is disabled, and test 240 reports always
fail because the string gets mangled ("test\n" --> "init_child_tty:
/dev/pts/13\ntest\n") when debugging is on.
However, when you look the output files, you will see that without mangling
only the other case would really fail.
Adjusting the wait value (from 0.1 to 0.5) doesn't make any difference.
Jussi
On Mon, Nov 24, 2014 at 1:15 AM, Jussi Lahtinen
wrote:
>
> 1) Can you try with revision #6671? It should not change anything, but
>> then we will run exactly the same code.
>>
>
> I did that and nothing seemed to change in regards of this problem, just
> like expected.
>
>
>
> 2) Can you uncomment the line #64 in the
>> '/trunk/main/gbx/gbx_c_process.c' source file before recompiling? That
>> way you will have many debugging message that will allow to know what
>> happens behind the curtain.
>>
>
> I recompiled with the debugging on, but this changed the situation.
> No more crash, but GambasTester gave error 239, which means the content of
> sTest was not "test" as expected.
> Instead the string contains "init_child_tty: /dev/pts/13\ntest\n", so I
> temporarily commented out the return line.
> Still, no more crashing.
> I attached output of non-crashing run, if there is any help from it.
>
> I will investigate more later.
>
>
>
> 3) In the future, will you modify your project to be purely command-line
>> (no dialog, no window, no GUI used at all)? Note that if you use a GUI
>> component, you use its event loop, not the one provided by the
>> interpreter. That may change the behaviour of bugs...
>>
>
> Yes I can do that, but not sure if I have understood this right...
> shouldn't there then be GambasTester for Qt4, GTK+ and for command line?
>
>
>
> Jussi
>
>
mTest.DoTests.364: This Gambas version is somewhat tested for string errors.
run_process 0xd4ab58: echo 'This Gambas version is somewhat tested for string
errors.' | md5sum
init_child()
fork: pid = 25520
watch: out = 3 err = 5
run_process: check child state immediately
run_process: child is OK
Waiting for 25520
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
>> callback_child
Process 25520 has returned 0
stop_process: 0xd4ab58
stop_process_after: 0xd4ab58
callback_error: 5 0xd4ab58
exit_process: 0xd4ab58
unwatch & close: 3
unwatch & close: 5
Raising Kill event for 0xd4ab58: parent = 0xd3df88 can raise = 0
exit_child()
<< callback_child
Waiting for: got it !
Process_free 0xd4ab58
exit_process: 0xd4ab58
run_process 0xd4ab58: echo test
run_process: slave = /dev/pts/12
init_child()
fork: pid = 25523
watch: out = 3 err = -1
run_process: check child state immediately
run_process: child is OK
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
callback_write: 3 0xd4ab58
unwatch & close: 3
>> callback_child
Process 25523 has returned 0
stop_process: 0xd4ab58
stop_process_after: 0xd4ab58
Raising Kill event for 0xd4ab58: parent = 0xd3df88 can raise = 0
exit_child()
<< callback_child
mTest.DoTests.1544: init_child_tty: /dev/pts/12
Process_free 0xd4ab58
exit_process: 0xd4ab58
ERROR: 240
mTest.DoTests.364: This Gambas version is somewhat tested for string errors.
run_process 0x1060b58: echo 'This Gambas version is somewhat tested for string
errors.' | md5sum
init_child()
fork: pid = 25532
watch: out = 3 err = 5
run_process: check child state immediately
run_process: child is OK
Waiting for 25532
callback_write: 3 0x1060b58
callback_write: 3 0x1060b58
callback_write: 3 0x1060b58
>> callback_child
Process 25532 has returned 0
stop_process: 0x1060b58
stop_process_after: 0x1060b58
callback_error: 5 0x1060b58
exit_process: 0x1060b58
unwatch & close: 3
unwatch & close: 5
Raising Kill event for 0x1060b58: parent = 0x1053f88 can raise = 0
exit_child()
<< callback_child
Waiting for: got it !
Process_free 0x1060b58
exit_process: 0x1060b58
run_process 0x1060b58: echo test
run_process: slave = /dev/pts/12
init_child()
fork: pid = 25535
watch: out = 3 err = -1
run_process: check child state immediately
run_process: child is OK
callback_write: 3 0x10
Re: [Gambas-user] Gambas Software Farm in revision #6676
On 11/25/2014 05:25 PM, Benoît Minisini wrote: > > Binary packages must be made for all distributions I would ask why must binary packages be made for all distributions (IMHO a huge undertaking), but you have answered that in the paragraph below. > The Gambas Farm allows to install any Gambas program in one click > whatever your Linux system is. And you have to upload only one package. That is definitely an awesome goal. But, I just have to wonder why is it necessary to go that far? If, as I thought, the Gambas Farm would be more of a source-code repository, compiling/packaging could be left up to the user, greatly simplifying things. However, if that particular decision has already been made, then my thoughts on it are moot. >> Now, for those who may wish to use the Farm as a >> (pseudo-)marketplace. I wonder if adding the ability to >> password-protect an application/component listing, like "published" >> and "private", would be worth considering. It would definitely not be >> ideal, but might be workable. >> > > Please elaborate. I don't know if I can elaborate much as it was just a conceptual idea. Wordpress allows pages/posts to be published as public or private. It is a similar concept but applied instead to application/component listings on the Farm. Conceptually, publishers could choose to password-protect their listing. It may be visible, with its description, in whatever directory or listing there is, or found through a search. But, to view the source code or to download/install the program would require a password that the user would need to get from the publisher. One of the reasons it is not ideal is that passwords can be easily shared. A publisher might, therefore, wish to periodically change the password for their listing. Again, not ideal, but maybe workable. For a true marketplace, specially coded (redirect) download links would likely be generated on-the-fly after payment processing. -- Lee __ "Artificial Intelligence is no match for natural stupidity." -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
Le 25/11/2014 17:55, T Lee Davidson a écrit : > On 11/25/2014 05:20 AM, B Bruen wrote: >> On Mon, 24 Nov 2014 14:11:54 +0100 Benoît Minisini >> wrote: >> >>> - Installing is not done. >> >> I still maintain that autotools is the way to go. It is, as far as >> I know, distro independent and complies with the desire to make the >> whole menagerie based on "source code visibility". The installer, >> apart from the nastiness checking previously posted, could use the >> existing code in the IDE to create an autotools package and then >> run the ".reconf;.configure;make;su(do) make install" circus to >> install it. > > Maybe I'm missing something, but why do all that? The IDE already has > a package maker. Why not just let the user make their own > application package and install from that? Gambas must be installed > to run the application anyway, right? > > Perhaps an option to install the package after its creation could be > added to the package maker. > Binary packages must be made for all distributions, and some distributions are not well supported, or not supported at all. The Gambas Farm allows to install any Gambas program in one click whatever your Linux system is. And you have to upload only one package. > >>> - In the future, the error message could be replaced by an >>> automatic installation of binary packages depending on the >>> distribution. I need help for that: for each distribution, I need >>> to know how to install a binary package, and if the distribution >>> follows the gambas binary package naming convention. >> >> As mentioned by Kevin, I would eschew binary installs. Too much >> danger. > > Not necessarily. People install binary packages from various > "unofficial" repositories all the time, like the Daily PPA. I think > the main issue with installing binary packages is: Is the repository > trusted. > > That being said, I think that doing binary installs of applications > published on the Farm just complicates things needlessly. But then > there are components which I have not worked with. Can they also be > made into packages via the IDE? > > Or are we talking about installing the necessary Gambas components > from the distribution's repository? The later. > > >>> - If there are dependencies of other softwares, then a recursive >>> search of all the dependencies is done, and the corresponding >>> software must be installed first. >> >> We have found that too hard. Better a message "Can't install, you >> need the zyxxy component to be installed first". > > That may be what Benoît was saying. > > >>> - The source package is downloaded, and stored in something like >>> '~/.local/gambas3/farm//'. >> >> Hmmm. Not sure. I have a feeling "~/Downloads" may be more >> friendly, or a configurable target. > > "~/Downloads" is not guaranteed to exist. So, if a hard-coded > '~/.local/gambas3/farm//' is not acceptable, then a > configurable target should be allowed. But, in my opinion, > '~/.local/gambas3/farm//' makes more sense since this > *is* a Gambas "thing", and "~/Downloads" can get cluttered just like > "~/Desktop" does. > See my answer in Bruen's mail. > > Now, for those who may wish to use the Farm as a > (pseudo-)marketplace. I wonder if adding the ability to > password-protect an application/component listing, like "published" > and "private", would be worth considering. It would definitely not be > ideal, but might be workable. > Please elaborate. Regards, -- Benoît Minisini -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] browse for samba shares
Le 24/11/2014 19:25, Federico Allegretti a écrit : > hello. > > In my daily work i need to connect to various samba share from my gambas > applications. > > Modern linux distro can mount "on the fly" a samba share when the user > select from the "browse dialog" a network share resource. > > could this feature be implemented in gambas dialogs like the FILECHOOSER? > > i really need to pass UNC like smb://server/share/folder/file.extension ... > any plan in that direction? > > thanks > > Federico :D > Not at the moment. This is a big job, and none of these urls are standard. I suggest you use 'fuse' in the meantime. Regards, -- Benoît Minisini -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
On 11/25/2014 05:20 AM, B Bruen wrote: > On Mon, 24 Nov 2014 14:11:54 +0100 > Benoît Minisini wrote: > >> - Installing is not done. > > I still maintain that autotools is the way to go. It is, as far as I know, > distro independent and complies with the desire to make the whole menagerie > based on "source code visibility". The installer, apart from the nastiness > checking previously posted, could use the existing code in the IDE to create > an autotools package and then run the ".reconf;.configure;make;su(do) make > install" circus to install it. Maybe I'm missing something, but why do all that? The IDE already has a package maker. Why not just let the user make their own application package and install from that? Gambas must be installed to run the application anyway, right? Perhaps an option to install the package after its creation could be added to the package maker. >> - In the future, the error message could be replaced by an automatic >> installation of binary packages depending on the distribution. I need >> help for that: for each distribution, I need to know how to install a >> binary package, and if the distribution follows the gambas binary >> package naming convention. > > As mentioned by Kevin, I would eschew binary installs. Too much danger. Not necessarily. People install binary packages from various "unofficial" repositories all the time, like the Daily PPA. I think the main issue with installing binary packages is: Is the repository trusted. That being said, I think that doing binary installs of applications published on the Farm just complicates things needlessly. But then there are components which I have not worked with. Can they also be made into packages via the IDE? Or are we talking about installing the necessary Gambas components from the distribution's repository? >> - If there are dependencies of other softwares, then a recursive search >> of all the dependencies is done, and the corresponding software must be >> installed first. > > We have found that too hard. Better a message "Can't install, you need the > zyxxy component to be installed first". That may be what Benoît was saying. >> - The source package is downloaded, and stored in something like >> '~/.local/gambas3/farm//'. > > Hmmm. Not sure. I have a feeling "~/Downloads" may be more friendly, or a > configurable target. "~/Downloads" is not guaranteed to exist. So, if a hard-coded '~/.local/gambas3/farm//' is not acceptable, then a configurable target should be allowed. But, in my opinion, '~/.local/gambas3/farm//' makes more sense since this *is* a Gambas "thing", and "~/Downloads" can get cluttered just like "~/Desktop" does. Now, for those who may wish to use the Farm as a (pseudo-)marketplace. I wonder if adding the ability to password-protect an application/component listing, like "published" and "private", would be worth considering. It would definitely not be ideal, but might be workable. -- Lee __ "Artificial Intelligence is no match for natural stupidity." -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
Am 24.11.2014 15:46, schrieb Benoît Minisini: > Le 24/11/2014 15:37, Rolf-Werner Eilert a écrit : >> As far as I know from KDE 3 and 4, >> >>> - A *.desktop file is created and installed in >>> '~/.local/share/applications' so that it appears in the desktop menu. >> >> the .desktop files are stored in ~/Desktop. On my system, >> firefox.desktop is the only one residing in ~/.local/share/applications >> and there is a copy of it in ~/Desktop. > > I'm talking about the desktop application menu: this is a > freedesktop.org standard. To add a menu entry, you have to install a > *.desktop file in that folder. Yes, I got you wrong here of course! > >> >> By the way, the farm is a very good idea! >> >> And it reminded me of your idea of a simple picture editor. I needed >> such a thing this weekend, but in lack of other software I used Gimp >> instead which is a bit of a functional dinosaur for just cutting an area >> from a smartphone photo and reducing the resulting picture to a smaller >> size... > > You can use the image editor of the IDE. It has a few bugs, but it is > useful for not so simple tasks. Ah, forgot about that one. But it was on my wife's laptop, and she doesn't have a Gambas installed :) > >> >> Thinking about your idea, I came to the point where it should be >> possible to just "install" such a program, with all dependencies (and >> the Gambas interpreter itself) installing automagically. >> >> As far as I understand, your farm will work like this. The only thing >> I'm not clear about is if you intend the farm to be for people just >> using the software or for potential Gambas programmers who want to take >> a look at the code? >> > > The last goal: the farm server can only host source code archive. The > source code is compiled on the user's system, but the source remains > available. > > In other words, it's not a "market place". :-) > Ok... I don't have any experience with such a thing, so I can't say what I would use it for. Maybe I'll find out later! Regards Rolf -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Gambas Software Farm in revision #6676
On Mon, 24 Nov 2014 14:11:54 +0100 Benoît Minisini wrote: > The recent news about Gambas Software Farm: > > - Many bug fixes. I am now getting quite excited about this. At the moment it appears that it will be a very good solution to our current very manual way of distributing new and updated software to our client base. > > - The farm configuration (server list, identities) has been removed from > the IDE option dialog, and is now in its own dialog. That way, the code > of the software farm is independent, and will be put in its own > executable (gambas3-farm) in the future. Definitely looking forward to the stand alone version! However, the configuration now looks a lot more logical. (I was having concerns about the modal nature of the whole publishing thing.) > > - Voting is now possible by clicking on the star button, as soon as you > are identified on the server. Each user can assing zero or one vote for > each software. The number displayed beside the star is the total number > of votes > One thing that isn't immediately apparent is that clicking on the star a second time seems to remove your vote? > - Installing is not done. I still maintain that autotools is the way to go. It is, as far as I know, distro independent and complies with the desire to make the whole menagerie based on "source code visibility". The installer, apart from the nastiness checking previously posted, could use the existing code in the IDE to create an autotools package and then run the ".reconf;.configure;make;su(do) make install" circus to install it. > > As for installing software, here are my thoughts: > > - The farm server will extract the ".project" file for the submitted > software to know about its component dependencies (not done). I am not sure what you are implying here but I think you are saying that if a published project has dependencies on an unpublished component, for example a non-native component then it will not be installable until the said non-native component is also published? > > - When installing, the farm client will download the ".project" file to > check these dependencies. If they do not match, an error message will be > displayed, and the installation will abort. And here I think you are saying that if a published project has dependencies on any component that is not installed on the local machine then the "installation" would fail with an appropriate message. In short, "Here be beasties!" or in Aussie "Been there, done that, seen the movie, bought the T-shirt ". The best solution we have come up with is, again autotools, including extra checks in the script along the lines of: AC_MSG_CHECKING(for required components - sysinfos.gambas) if !(test -e /usr/lib/gambas3/sysinfos.gambas); then AC_MSG_RESULT(Not found) AC_MSG_ERROR(Required libraries must be installed BEFORE this package) else AC_MSG_RESULT(Ok) fi With a bit of thought I could probably modify our autotools installer to generate these required checks automatically... > > - In the future, the error message could be replaced by an automatic > installation of binary packages depending on the distribution. I need > help for that: for each distribution, I need to know how to install a > binary package, and if the distribution follows the gambas binary > package naming convention. As mentioned by Kevin, I would eschew binary installs. Too much danger. > > - If there are dependencies of other softwares, then a recursive search > of all the dependencies is done, and the corresponding software must be > installed first. We have found that too hard. Better a message "Can't install, you need the zyxxy component to be installed first". > > - The source package is downloaded, and stored in something like > '~/.local/gambas3/farm//'. Hmmm. Not sure. I have a feeling "~/Downloads" may be more friendly, or a configurable target. > > - The software is compiled on the user's computer, and the executable is > installed in '~/.local/gambas3/bin/'. Q'est que se? (whatever, it's been 40++ years since high school French!) Surely the compiled executable should go into the (default) project directory.. I think that promoting a compiled program to executable status is a matter for the user. Again, given Kevin's comments, I would like to see an ability to 1) download the source code to a selected area 2) review the code via the IDE, with some possible assistance regarding "this program converses with the internet at large" etc 3) make my own decision as to whether to install the said program in any automatically executable directory. 4) only install it with a locally executed su(do) command or utility. > > - A *.desktop file is created and installed in > '~/.local/share/applications' so that it appears in the desktop menu. I think this should only happen if the project is a "Normal". > > Waiting for your comments! You got em. > > -- > Benoît Minisini > Most
[Gambas-user] Issue 585 in gambas: free() invalid pointer exit in cli project running trunk
Status: New Owner: Labels: Version Type-Bug Priority-Medium OpSys-Any Dist-Any Arch-Any Desktop-Any GUI-Any New issue 585 by r...@cyberjunky.nl: free() invalid pointer exit in cli project running trunk https://code.google.com/p/gambas/issues/detail?id=585 1) Describe the problem. When running my cli project with latest trunk (from today) upon Ctrl-C to stop it if will give : free(): invalid pointer: 0xb5f28580 *** Aborted 2) Give information about your system. Use the 'System information' menu in the Gambas IDE, and paste the result there. Not possible headless system. 3.4.79-sun7i+ #1 SMP PREEMPT Sun May 4 12:31:58 CEST 2014 armv7l armv7l armv7l GNU/Linux 3) Indicate the Gambas version in the issue labels, and if it is a bug, a crash, or an enhancement request. 4) Provide a little project that reproduces the bug or the crash. Not succeeded to extract issue from my big project yet. 5) If your project needs a database, try to provide it, or part of it. 6) Explain clearly how to reproduce the bug or the crash. Exit my project with ctrl-C, it's to big to provide. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
