Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: RE: saving local macros


From   "Ashim Kapoor" <[email protected]>
To   [email protected]
Subject   Re: st: RE: saving local macros
Date   Wed, 7 Jan 2009 23:03:59 +0530

Hi Nick,

I don't think I was clear. Here is what I do :
1. Run sometests and produce local macros and a small output dataset.
2. Use the macros and dataset to print the output.

so (2) is ALL I want any1 to see. I am not worried about encrypting
the local macros, only that I can't let anyone else see the do file i
am running to produce my macro.

Is'nt is much easier to save the macros / save the dataset and send it
to someone to see the output whethere in HTML or smcl.
Why risk someone decrypting my file ?

It's not even my IDEA, I just program it but I don't think my boss
will like it if i put it on the internet.

Is'nt everyone who comes to this list  working for a company or a
university ? Would'nt their university be really upset if they gave
out their bosses unpublished work on the internet and fire them on the
spot ? Do those people pay for these services  ? Oh, A small number of
times I have answered questions, should I expect to be paid for that ?

Thank you,
Ashim.

On Wed, Jan 7, 2009 at 10:48 PM, Nick Cox <[email protected]> wrote:
> Sorry, Ashim, but I really don't understand your comments here.
>
> First off, local macros are useless unless used in some code. Whether
> that use is interactive, via a do file, or via a program is up to you.
>
> If you want to be absolutely sure that certain collaborators, and only
> those collaborators, see that code, then you need to send it encrypted.
> That would apply to a do file or a program, and does not _itself_ rule
> out do files.
>
> Second, saving macros in the data file runs into the same issues. You
> would need to encrypt that too, as any Stata user with the same version
> could in principle read your data file too.
>
> In short, wanting absolute security seems to me orthogonal to all other
> details here.
>
> For myself, I always remember what Howard Aiken said. Don't worry about
> people stealing your ideas; if they're any good, you will have to ram
> them down their throats.
>
> Nick
> [email protected]
>
> P.S. If you are developing proprietary code, why do you expect free
> help? Shouldn't you offer to pay us?
>
> Ashim Kapoor
>
> Well in my opinion the do file won't do. Simply because the 1st half
> of my code is proprietary, I dont wnat any1 to see it. I do wnat them
> to USE the local macros / dataset at the end of the 1st half. Maybe I
> am more clear now.
>
> On Wed, Jan 7, 2009 at 10:26 PM, Nick Cox <[email protected]> wrote:
>
>> A matrix could not be used for macros with string content. (Strictly,
>> all macros are strings, but clearly some have numeric content.)
>>
>> Nick
>> [email protected]
>>
>> Philipp Rehm
>>
>> I think that's what do-files are for.
>>
>> Nevertheless: how about building up a matrix which contains the local
>> macros you encounter, which you then save into a variable? You could
>> then recover the local macros with -levelsof-, for example.
>>
>> But I guess a do-file is the more straightforward approach...
>>
>>
>> Ashim Kapoor wrote:
>>> I somehow feel that you can save local macros in a way other than
>>> using -notes- can you ??
>>>
>>
>> *
>> *   For searches and help try:
>> *   http://www.stata.com/help.cgi?search
>> *   http://www.stata.com/support/statalist/faq
>> *   http://www.ats.ucla.edu/stat/stata/
>>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
>
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index