janko metelko | 1 Sep 01:04 2008
Picon

Re: fry and curry

I am not at my factor computer so can't try it right now , but will tomorrow.

refactr? these web 2.0 names are really science of it's own :) they
have a db error on their page.

I have to call it refaktor because we can't have company names with
english words ... it's just a company name... my "web 2.0 startup"-ish
projects are named various other names.

BR
Janko

On Mon, Sep 1, 2008 at 12:55 AM, Slava Pestov <slava@...> wrote:
> Entering ``"fry" about'' in the listener will explain what it's all about.
>
> And FWIW, there is already a ``Web 2.0'' startup named REFACTR:
> http://refactr.com/ :-)
>
> Slava
>
> On Sun, Aug 31, 2008 at 5:52 PM, janko metelko <janko.itm@...> wrote:
>>
>> I have used curry but I haven't fry and I don't know what fry does ...
>> but looking at the two examples you posted ... fry versions look
>> strange to me. this is just "looks" based oppinion.. take it as so..
>>
>> btw and OT ... I am upgrading my company and I renamed it to REFAKTOR
>> LTD ... your little pesky language was the positive inspiration at
>> finding some idea to name it after :)
>>
(Continue reading)

Eduardo Cavazos | 1 Sep 01:16 2008
Picon

RESOLVE: form

Moving this to 'factor-talk' so others can chime in. You give a good enough 
description below so that others can catch up.

Slava wrote:

> We figured this out. Doug added a 'second' word to calendar which shadowed
> sequences:second in ui.gestures.
>
> This took me 5 minutes to bootstrap and another 5 to debug. Adding the time
> Doug spent on this, we have about half an hour of lost work between the two
> of us.
>
> Let me again propose the feature where if you have a:foo and b:foo, then
> USING: a b ; foo, you get a parse time error about ambiguity in the search
> order. A RESOLVE: parsing word could be used to specify which one you want,
> so adding RESOLVE: a foo or RESOLVE: b foo would solve the parse error. If
> this had been a parse error, Doug could've bootstrapped and Factor would've
> immediately indicated that something was wrong. He would see a message much
> like the following:
>
> The word "second" is defined in more than one vocabulary in the search path
> but no RESOLVE: form was given.
>
> Restarts:
>
> 1: Use calendar
> 2: Use sequences
>
> This would have enabled him to fix the issue in a matter of seconds and
> saved us both time.
(Continue reading)

Slava Pestov | 1 Sep 01:53 2008

Re: RESOLVE: form

On Sun, Aug 31, 2008 at 6:16 PM, Eduardo Cavazos <wayo.cavazos-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Let's say vocabularies X Y Z use vocabulary A. I edit A. I refresh-all. Let's
suppose that 'refresh-all' has the proposed behaviour whereby it refreshes X
Y and Z since they depend on A (I believe you mentioned that this is a
planned feature).

This is not a planned feature. I invest considerable time into getting the compiler to recompile the right words when a source file is reloaded precisely so that I don't need to do this. It would be annoying to change and reload 'sequences' and then have every other file reload and recompile because they depend on it.

So this is going to lead to a situation where I am constrained about how I
name things in my vocabulary based on how *others* use it. The whole freedom
to name is now impeded a bit.

The other alternative is that X, Y, and Z stop working and you have no indication until you try using words from those vocabs (which might be 6 months later).
 
Moreover, the above notifications about how I'm impacting other vocabularies
*only* happen if I happen to have X, Y, and Z loaded. What about all the
stuff in the CFAN (CPAN for factor...)? I'm not going to know I'm impacting
any of that. What about stuff that's in 'extra' that I haven't bothered to
load?

You can't avoid breaking other code sometimes by changing names. The point is to detect the problem as early as possible: at parse time, not run time.
 
Here's something else to consider. Your complaint is that the shadowing
occured but you weren't notified about it. It's quite possible that when such
shadowing occurs, you'll get compile time errors because of a mismatched
stack effect. Did you not see such errors after Doug added 'second' to
calendar? This sort of detection is only going to go up as folks use types in
their effects more often and the compiler gets better at detecting
inconsistencies.

Both sequences:second and calendar:second have the same effect ( a -- b ) so the compiler didn't complain.

If you have a static type system like the one found in ML and Haskell, you don't need things like this because type signatures can be very precise, but we shouldn't postpone improvements which can benefit us immediately based on some blue-sky feature which or may not materialize.

Slava
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk
Doug Coleman | 1 Sep 01:57 2008
Picon

Re: RESOLVE: form

I didn't see any compiler errors when I added the 'ALIAS: second  
seconds' to calendar.  In fact, Factor didn't even throw the popup  
exception until I bootstrapped again.  I could have been using the  
same image for a few more days and made lots of commits before ever  
having to bootstrap again.  I've been hit by this shadowing bug at  
least four times and every time it takes a lot of debugging and WTFs  
to find a solution.

To address the hypothetical problem, if you're editing A, and X Y Z  
depend on A, then A is some sort of library, utility, or component of  
X Y Z and you should therefore have to fix X Y Z too.  If, on the  
other hand, A is using X Y Z and something in one of those causes a  
resolve error, then X Y Z are the libraries and you are writing some  
kind of application.  If the libraries change, then it's fine to have  
the application writer update his code.  Libraries need to be written  
with more care than applications so that they are reusable, and this  
means avoiding common word names or adding lots of RESOLVE:s.

Doug

On Aug 31, 2008, at 6:16 PM, Eduardo Cavazos wrote:

> Moving this to 'factor-talk' so others can chime in. You give a good  
> enough
> description below so that others can catch up.
>
> Slava wrote:
>
>> We figured this out. Doug added a 'second' word to calendar which  
>> shadowed
>> sequences:second in ui.gestures.
>>
>> This took me 5 minutes to bootstrap and another 5 to debug. Adding  
>> the time
>> Doug spent on this, we have about half an hour of lost work between  
>> the two
>> of us.
>>
>> Let me again propose the feature where if you have a:foo and b:foo,  
>> then
>> USING: a b ; foo, you get a parse time error about ambiguity in the  
>> search
>> order. A RESOLVE: parsing word could be used to specify which one  
>> you want,
>> so adding RESOLVE: a foo or RESOLVE: b foo would solve the parse  
>> error. If
>> this had been a parse error, Doug could've bootstrapped and Factor  
>> would've
>> immediately indicated that something was wrong. He would see a  
>> message much
>> like the following:
>>
>> The word "second" is defined in more than one vocabulary in the  
>> search path
>> but no RESOLVE: form was given.
>>
>> Restarts:
>>
>> 1: Use calendar
>> 2: Use sequences
>>
>> This would have enabled him to fix the issue in a matter of seconds  
>> and
>> saved us both time.
>
> OK. This is a nice real world example of the problem. But when you  
> say "Let me
> again propose the feature..." I'm taking that to mean "propose for  
> further
> analysis" and not "propose for immediate inclusion". Let's think  
> about how
> this would impact things.
>
> Let's say vocabularies X Y Z use vocabulary A. I edit A. I refresh- 
> all. Let's
> suppose that 'refresh-all' has the proposed behaviour whereby it  
> refreshes X
> Y and Z since they depend on A (I believe you mentioned that this is a
> planned feature). Alright, let's say the above problem scenario  
> occurs; a new
> word in A shadows a word from a vocabulary that X Y and Z use. When  
> I do my
> refresh-all I'm going to get error messages about how the change is  
> causing
> problems in X Y and Z.
>
> So this is going to lead to a situation where I am constrained about  
> how I
> name things in my vocabulary based on how *others* use it. The whole  
> freedom
> to name is now impeded a bit.
>
> Moreover, the above notifications about how I'm impacting other  
> vocabularies
> *only* happen if I happen to have X, Y, and Z loaded. What about all  
> the
> stuff in the CFAN (CPAN for factor...)? I'm not going to know I'm  
> impacting
> any of that. What about stuff that's in 'extra' that I haven't  
> bothered to
> load?
>
> I also have a request. Let's do an analysis of the current code  
> base. Let's
> suppose RESOLVE: were implemented. How many vocabularies would be  
> impacted?
>
> Here's something else to consider. Your complaint is that the  
> shadowing
> occured but you weren't notified about it. It's quite possible that  
> when such
> shadowing occurs, you'll get compile time errors because of a  
> mismatched
> stack effect. Did you not see such errors after Doug added 'second' to
> calendar? This sort of detection is only going to go up as folks use  
> types in
> their effects more often and the compiler gets better at detecting
> inconsistencies.
>
> Maybe it's a good and necessary idea. I'm just trying to think about  
> it.
>
> Ed
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Eduardo Cavazos | 1 Sep 02:08 2008
Picon

RESOLVE: for unused words

Slava wrote:

> Let me again propose the feature where if you have a:foo and b:foo, then
> USING: a b ; foo, you get a parse time error about ambiguity in the search
> order.

What happens if the vocabulary using 'a' and 'b' doesn't refer to 'foo'? Will 
the error occur?

That would be mighty annoying if I'm using some vocabularies and have to 
RESOLVE: words that I don't even use.

Ed

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Slava Pestov | 1 Sep 02:10 2008

Re: RESOLVE: for unused words

You won't have to resolve words you don't use.

Suppose you have two words, a:foo and b:foo. You will be able to do

USING: a b ;
IN: my-vocab

Without further qualifications, as long as you don't refer to 'foo'.

You'll only have to RESOLVE: a/b foo if you refer to 'foo'. The other alternative would be to only USE: one of a and b, and use QUALIFIED: for the other one.

Slava

On Sun, Aug 31, 2008 at 7:08 PM, Eduardo Cavazos <wayo.cavazos-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Slava wrote:

> Let me again propose the feature where if you have a:foo and b:foo, then
> USING: a b ; foo, you get a parse time error about ambiguity in the search
> order.

What happens if the vocabulary using 'a' and 'b' doesn't refer to 'foo'? Will
the error occur?

That would be mighty annoying if I'm using some vocabularies and have to
RESOLVE: words that I don't even use.

Ed

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/factor-talk

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk
Eduardo Cavazos | 1 Sep 02:14 2008
Picon

RESOLVE: and QUALIFIED:

Slava wrote:

> Let me again propose the feature where if you have a:foo and b:foo, then
> USING: a b ; foo, you get a parse time error about ambiguity in the search
> order.

We currently have ways to address the problem. For one, there is no ambiguity 
because the USING: order determines which one is referred to. It's not 
exactly correct to call this an ambiguity problem.

What happens if the user of 'a' and 'b' decides to deal with the problem using 
the tools provided by qualified. Will they be allowed to? Will they be forced 
to use RESOLVE: instead even if QUALIFIED: does the job?

Perhaps your proposal should be viewed as two separate items.

One: throw a parse time error if more than one used vocabulary exports the 
same name which is in turn used by the using vocabulary.

Two: A 'RESOLVE:' form which can solve the above issue. This would be in 
addition to other tools which are available to fix the problem.

Ed

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Eduardo Cavazos | 1 Sep 02:16 2008
Picon

Re: RESOLVE: for unused words

Slava Pestov wrote:

> You won't have to resolve words you don't use.

OK that's good. Then disregard the email that's on the way. :-)

Ed

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Chris Double | 1 Sep 02:22 2008
Picon

Re: RESOLVE: form

I've also hit this problem a few times and it's difficult to track
down. If there were a parse time error it would be easier.

If I change peg for example to add a new word that shadows something
in a users vocab, that user would probably like to know straight away
when they next update via a 'resolve error' or similar. Otherwise
they'll get odd, hard to track down, errors with no idea what could
have caused it.

Chris.
--

-- 
http://www.bluishcoder.co.nz

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Slava Pestov | 1 Sep 02:27 2008

Re: <CFNumber> still references c-types at runtime in deployed image. Not sure why

Hi Joe,

This problem has been fixed. I have tested the deploy tool with a few simple examples and the unit tests pass. Let me know if you have any other problems.

Slava

On Sun, Aug 31, 2008 at 12:51 PM, Joe Groff <arcata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I was trying to deploy an image, and the resulting app is bombing out
with a "no-c-type" exception inside a call to <CFNumber>. Now it's no
big deal to switch on "deploy-c-types?", but looking at the definition
of <CFNumber> in core-foundation, it seems like it shouldn't need the
c-types at runtime:

GENERIC: <CFNumber> ( number -- alien )
M: integer <CFNumber>
    [ f kCFNumberLongLongType ] dip <longlong> CFNumberCreate ;
M: float <CFNumber>
    [ f kCFNumberDoubleType ] dip <double> CFNumberCreate ;
M: t <CFNumber>
    drop f kCFNumberIntType 1 <int> CFNumberCreate ;
M: f <CFNumber>
    drop f kCFNumberIntType 0 <int> CFNumberCreate ;

Is there something here I'm missing that prevents the optimizing
compiler picking out the <c-object> calls? Calling infer on each
method definition gives the expected (( object -- object )), and "core-
foundation" reload doesn't emit any warnings or errors.

-Joe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/factor-talk

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk

Gmane