pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] RegexPlor demo (Was: PyObjC- vs. Python Unicode)

[Jack J. <Jac...@cw...>]

On Wednesday, Jul 2, 2003, at 16:30 Europe/Amsterdam, Dinu Gherman 
wrote:
> I just added a screenshot:
>
>     http://python.net/~gherman/tmp/RegexPlor0.jpg

Nice! Thanks for the screenshot, I can't run the code right now, it's 
good
to see what it looks like.

BTW: have you seen <http://kodos.sourceforge.net/home.html>? The 
interface
looks a bit clunky, but it has some nice features, such as the ability 
to look
at group matches, selecting which match to show and the generation of
Python code.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pyobjc-dev] Re: cvs snapshots?

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> I think the problem here is that gnutar and OSX-tar are not 100%
> compatible. To make matters worse, once you use fink it will install
> a GNU tar in 
> /sw/bin
> with the name "tar", and it obscures OSX tar. The result of this is
> that you create tarfiles that cannot be read by people who have only
> a basic OSX installation. I got bitten by this a while ago.

Note that the snapshot tar files are created on a Linux shell box @ sf,
but I have no idea what tar version that is.

Just

Re: [Pyobjc-dev] Re: cvs snapshots?

[Jack J. <Jac...@cw...>]

On Wednesday, Jul 2, 2003, at 16:00 Europe/Amsterdam, Just van Rossum 
wrote:

> Michael Hudson wrote:
>
>> I get a bunch of these:
>>
>> tar: Unable to create pyobjc/ProjectBuilder Extras/Project
>> Templates/Cocoa-Python Application/English.lproj/MainMenu.nib/ <Is a
>> directory>
>
> Hm, I rather get messages like
>
> pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
> Application/CocoaApp.pbproj/CVS/Entries
> ././@LongLink
> pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
> Application/CocoaApp.pbproj/TemplateInf
> ././@LongLink

I think the problem here is that gnutar and OSX-tar are not 100% 
compatible.
To make matters worse, once you use fink it will install a GNU tar in 
/sw/bin
with the name "tar", and it obscures OSX tar. The result of this is 
that you
create tarfiles that cannot be read by people who have only a basic OSX
installation. I got bitten by this a while ago.

And if you remove /sw/bin/tar (keeping /sw/bin/gnutar) the next time 
you run
fink it will happily install it again:-(
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

[Pyobjc-dev] RegexPlor demo (Was: PyObjC- vs. Python Unicode)

[Dinu G. <gh...@da...>]

I wrote:

>   http://python.net/~gherman/tmp/RegexPlor.tar.gz
>
> Maybe a nice demo...? The source can be improved, but it's
> been only a one hour hack... Notice the ability to change text
> fonts and sizes!

I just added a screenshot:

     http://python.net/~gherman/tmp/RegexPlor0.jpg

Dinu

--
Dinu C. Gherman
......................................................................
"A whole generation has grown up with the idea that it is normal
for them to have no freedom." (Richard M. Stallman)

Re: [Pyobjc-dev] Re: cvs snapshots?

[Just v. R. <ju...@le...>]

Michael Hudson wrote:

> I get a bunch of these:
> 
> tar: Unable to create pyobjc/ProjectBuilder Extras/Project
> Templates/Cocoa-Python Application/English.lproj/MainMenu.nib/ <Is a
> directory>

Hm, I rather get messages like

pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
Application/CocoaApp.pbproj/CVS/Entries
././@LongLink
pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python
Application/CocoaApp.pbproj/TemplateInf
././@LongLink

> when unpacking... but using 'gnutar' works.  Would guess this is the
> recently-mentioned on python-dev tar problem...

Sounds like it. Btw. StuffIt Expander also extracts the files correctly.

(Btw. I also dislike the spaces in the folder names; our checkin
messages script doesn't like these, or at least I never see diffs of
files inside those folders.)

Just

[Pyobjc-dev] Re: cvs snapshots?

[Michael H. <mw...@py...>]

Just van Rossum <ju...@le...> writes:

> b.bum wrote:
>
>> On Tuesday, July 1, 2003, at 2:49 PM, Just van Rossum wrote:
>> > For my fonttools.sf project I use a (found) Python script that does
>> > a checkout and builds tarballs. It's a nightly cron job. However,
>> > I'm pretty sure it does an anon pserver checkout, so it probably
>> > suffers the same problems. Hm. It would still be useful for people
>> > not comfortable with CVS, though.
>> 
>> Could we use the build servers to good effect here?
>
> I run it on a regular shell server at sf.
>
> I thought it would be trivial to get it running for pyobjc as well, but
> it turned out the script contained a bug that caused it to fail as soon
> as there are folders with spaces in their names. I managed to fix that,
> though, and now I have a nightly cron job running, outputting stuff at
>
>   http://pyobjc.sourceforge.net/cvs-snapshots/
>
> Please wait with advertizing it on the site until we're absolutely sure
> things work correctly.

I get a bunch of these:

tar: Unable to create pyobjc/ProjectBuilder Extras/Project Templates/Cocoa-Python Application/English.lproj/MainMenu.nib/ <Is a directory>

when unpacking... but using 'gnutar' works.  Would guess this is the
recently-mentioned on python-dev tar problem...

Cheers,
M.

-- 
  Famous remarks are very seldom quoted correctly.
                                                    -- Simeon Strunsky

Re: [Pyobjc-dev] PyObjC- vs. Python Unicode

[Ronald O. <ous...@ci...>]

On Wednesday, Jul 2, 2003, at 13:58 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> SRE doesn't work because it tests types using '=='
>> instead of 'isinstance'. IMHO this is a bug in SRE.
>
> I agree. Do you report it or shall I do it? I think it's important to
> get this fixed before 2.3 final.

bug #764548

Ronald

Re: [Pyobjc-dev] PyObjC- vs. Python Unicode

[Dinu G. <gh...@da...>]

Ronald Oussoren:

>> Is their some canonical mechanism to convert to the true Python Uni-
>> code type?
>
> unicode(value)

Great! The immediate outcome of this is the following regular
expression explorer (I'm sure you've also got dozens of ideas
for extending it ;-):

   http://python.net/~gherman/tmp/RegexPlor.tar.gz

Maybe a nice demo...? The source can be improved, but it's
been only a one hour hack... Notice the ability to change text
fonts and sizes!

Dinu

--
Dinu C. Gherman
......................................................................
"The whole point of brainwashing, is that those being brainwashed
don't know it." (Graham Haley)

Re: [Pyobjc-dev] PyObjC- vs. Python Unicode

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> SRE doesn't work because it tests types using '==' 
> instead of 'isinstance'. IMHO this is a bug in SRE.

I agree. Do you report it or shall I do it? I think it's important to
get this fixed before 2.3 final.

Just

Re: [Pyobjc-dev] PyObjC- vs. Python Unicode

[Ronald O. <ous...@ci...>]

On Wednesday, Jul 2, 2003, at 13:15 Europe/Amsterdam, Dinu Gherman 
wrote:

> Hi,
>
> I'm taking a Unicode string out of an NSTextField, but its type seems
> to be <type 'objc.pyobjc_unicode'>, not quite like <type 'unicode'>
> which I'd like to feed into a regular expression using the re module
> (with Unicode mode). Now I'm getting a TypeError for re.compile.

Arghhh... we cannot use the plain unicode to represent ObjC strings 
because you may want to directly access the ObjC string, maybe because 
it is a mutable string or because you want to use one of the gazillion 
methods that have no direct python equivalent. We decided to subclass 
the unicode type to make it easier to use ObjC strings in python: 
Passing them to extension modules expecting strings or unicode objects 
"just works".  SRE doesn't work because it tests types using '==' 
instead of 'isinstance'. IMHO this is a bug in SRE.

>
> Is their some canonical mechanism to convert to the true Python Uni-
> code type?

unicode(value)

Ronald

[Pyobjc-dev] PyObjC- vs. Python Unicode

[Dinu G. <gh...@da...>]

Hi,

I'm taking a Unicode string out of an NSTextField, but its type seems
to be <type 'objc.pyobjc_unicode'>, not quite like <type 'unicode'>
which I'd like to feed into a regular expression using the re module
(with Unicode mode). Now I'm getting a TypeError for re.compile.

Is their some canonical mechanism to convert to the true Python Uni-
code type?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"I want to put a ding in the universe." (Steve Jobs)

Re: [Pyobjc-dev] PyShellView?

[Ronald O. <ous...@ci...>]

On Wednesday, Jul 2, 2003, at 10:32 Europe/Amsterdam, Dinu Gherman  
wrote:

> I wrote:
>
>> Sounds good to me! You may want to sniff into the following maybe:
>>
>>    
>> http://developer.apple.com/samplecode/Sample_Code/Cocoa/ 
>> TextViewDelegate.htm
>>
>> Have fun,
>
> Big fun, indeed!! The following conversion to PyObjC using an outlet
> named 'committedLength' of type id in IB just crashes:

I cannot reproduce this here using the attached files and  
'English.lproj' from the example. the main.py is your crashing code  
with an added call to NSApplication main, and adapted for the name of  
the nib inside the example.

Could you post a complete, crashing, example.

<later>

Now that I look at your message again I see what's wrong: don't use  
outlets to store the committedLength. If you store anything in outlets  
you must make sure that that object stays alive by other means (e.g.  
store a reference in a regular instance variable or even call  
'retain'). That doesn't help for "plain python" value though, therefore  
you shouldn't store plain-python values in outlets. I'm going to add  
something about this issue to the documentation.

Basic guideline: Only use outlets if you're going to set them from  
Interface Builder, otherwise use "regular" instance variables.

Ronald

Re: [Pyobjc-dev] cvs snapshots?

[Just v. R. <ju...@le...>]

b.bum wrote:

> On Tuesday, July 1, 2003, at 2:49 PM, Just van Rossum wrote:
> > For my fonttools.sf project I use a (found) Python script that does
> > a checkout and builds tarballs. It's a nightly cron job. However,
> > I'm pretty sure it does an anon pserver checkout, so it probably
> > suffers the same problems. Hm. It would still be useful for people
> > not comfortable with CVS, though.
> 
> Could we use the build servers to good effect here?

I run it on a regular shell server at sf.

I thought it would be trivial to get it running for pyobjc as well, but
it turned out the script contained a bug that caused it to fail as soon
as there are folders with spaces in their names. I managed to fix that,
though, and now I have a nightly cron job running, outputting stuff at

  http://pyobjc.sourceforge.net/cvs-snapshots/

Please wait with advertizing it on the site until we're absolutely sure
things work correctly.

Just

Re: [Pyobjc-dev] PyShellView?

[Dinu G. <gh...@da...>]

I wrote:

> Sounds good to me! You may want to sniff into the following maybe:
>
>    
> http://developer.apple.com/samplecode/Sample_Code/Cocoa/ 
> TextViewDelegate.htm
>
> Have fun,

Big fun, indeed!! The following conversion to PyObjC using an outlet
named 'committedLength' of type id in IB just crashes:

#------------------------------------------------------------------
#
#  MyAppDelegate.py
#  PyTextViewDelegate
#

from objc import YES, NO
from Foundation import NSObject
from AppKit import NSColor, NSApplicationDelegate
from PyObjCTools import NibClassBuilder

# create ObjC classes as defined in MainMenu.nib
NibClassBuilder.extractClasses("MainMenu")


class MyAppDelegate(NibClassBuilder.AutoBaseClass,  
NSApplicationDelegate):

     def awakeFromNib(self):
         "Set our committedLength outlet to the right start value."

         self.committedLength = 0


     def textView_shouldChangeTextInRange_replacementString_(self,
             textView, charRange, replString):
         "Allow editing only after the previously committed text."

         return charRange[0] >= self.committedLength
#------------------------------------------------------------------

But after using an instance variable 'cl' locally defined in
awakeFromNib everything works fine and I get the following code
working as the ObjC-counterpart:

#------------------------------------------------------------------
#
#  MyAppDelegate.py
#  PyTextViewDelegate
#

from objc import YES, NO
from Foundation import NSObject
from AppKit import NSColor, NSApplicationDelegate
from PyObjCTools import NibClassBuilder

# create ObjC classes as defined in MainMenu.nib
NibClassBuilder.extractClasses("MainMenu")


class MyAppDelegate(NibClassBuilder.AutoBaseClass,  
NSApplicationDelegate):

     def awakeFromNib(self):
         "Set our committedLength outlet to the right start value."

         # self.committedLength = 0
         self.cl = 0


     def textView_shouldChangeTextInRange_replacementString_(self,
             textView, charRange, replString):
         "Allow editing only after the previously committed text."

         return charRange[0] >= self.cl


     def textView_doCommandBySelector_(self, textView, commandSelector):
         "When return is entered, record and color the newly committed  
text."

         retval = NO

         if commandSelector == "insertNewline:":
             textLength = len(textView.string())
             if textLength > self.cl:
                 textView.setSelectedRange_((textLength, 0))
                 textView.insertText_("\n")
                 col = NSColor.redColor()
                 r = (self.cl, textLength - self.cl)
                 textView.setTextColor_range_(col, r)
                 textLength += 1
                 self.cl = textLength

             retval = YES

         return retval
#------------------------------------------------------------------

Nothing to do with using the NSTextViewDelegate - tried it, makes
no difference!

Pretty strange to me...

Dinu

--
Dinu C. Gherman
......................................................................
"We're concerned about AIDS inside our White House - make no mistake
about it." (George W. Bush, 7 Feb. 2001)

Re: [Pyobjc-dev] PyShellView?

[Dinu G. <gh...@da...>]

Michael Hudson:

> For a PyObjC application I want to write, I really really want to have
> a Python shell view, i.e. an area I can type Python commands into and
> have them executed interactively.  I should have few problems with the
> Python side -- I seem to do things like this all the time -- but the
> Cocoa side is considerably more mysterious to me.

Sounds good to me! You may want to sniff into the following maybe:

    
http://developer.apple.com/samplecode/Sample_Code/Cocoa/ 
TextViewDelegate.htm

Have fun,

Dinu

--
Dinu C. Gherman
......................................................................
"The pure and simple truth is rarely pure and never simple."
(Oscar Wilde)

Re: [Pyobjc-dev] cvs snapshots?

[b.bum <bb...@ma...>]

On Tuesday, July 1, 2003, at 2:49 PM, Just van Rossum wrote:
> For my fonttools.sf project I use a (found) Python script that does a
> checkout and builds tarballs. It's a nightly cron job. However, I'm
> pretty sure it does an anon pserver checkout, so it probably suffers 
> the
> same problems. Hm. It would still be useful for people not comfortable
> with CVS, though.

Could we use the build servers to good effect here?

b.bum

Re: [Pyobjc-dev] cvs snapshots?

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> What's the easiest way to automaticly make these snapshots? I could  
> write a script that does a 'cvs export' and creates a tarball of the  
> result, but I'm not sure if that is the best way to deal with this.

Here's what I use (needs editing, the configuration is in the code!).
It's from a guy named Eric Sunshine, the output is way more elaborate
than what I needed, but it does the job just fine.

Just

Re: [Pyobjc-dev] cvs snapshots?

[Ronald O. <ous...@ci...>]

What's the easiest way to automaticly make these snapshots? I could  
write a script that does a 'cvs export' and creates a tarball of the  
result, but I'm not sure if that is the best way to deal with this.

Ronald

On Tuesday, Jul 1, 2003, at 19:43 Europe/Amsterdam, Michael Hudson  
wrote:

> Given SF's current attitude to anon CVS, is it possible to make
> available snapshots of the state of CVS semi-regularly?
>
> Cheers,
> M.
>
> --  
>   ARTHUR:  Don't ask me how it works or I'll start to whimper.
>                    -- The Hitch-Hikers Guide to the Galaxy, Episode 11
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/ 
> 01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] cvs snapshots?

[Just v. R. <ju...@le...>]

Bob Ippolito wrote:

> > Given SF's current attitude to anon CVS, is it possible to make
> > available snapshots of the state of CVS semi-regularly?
> 
> SF *should* already do this, a nightly tarball sits at a url like
> this: http://cvs.sourceforge.net/cvstarballs/pyobjc-cvsroot.tar.gz (I
> can't verify the accuracy of this because SF is not responding at all
> for me right now).
> 
> However, I think that this is the actual repository, not a checkout..

I'm pretty sure it's indeed the repository...

For my fonttools.sf project I use a (found) Python script that does a
checkout and builds tarballs. It's a nightly cron job. However, I'm
pretty sure it does an anon pserver checkout, so it probably suffers the
same problems. Hm. It would still be useful for people not comfortable
with CVS, though.

Just

Re: [Pyobjc-dev] cvs snapshots?

[Bob I. <bo...@re...>]

On Tuesday, Jul 1, 2003, at 13:43 America/New_York, Michael Hudson 
wrote:

> Given SF's current attitude to anon CVS, is it possible to make
> available snapshots of the state of CVS semi-regularly?

SF *should* already do this, a nightly tarball sits at a url like this: 
  http://cvs.sourceforge.net/cvstarballs/pyobjc-cvsroot.tar.gz (I can't 
verify the accuracy of this because SF is not responding at all for me 
right now).

However, I think that this is the actual repository, not a checkout..

-bob

[Pyobjc-dev] cvs snapshots?

[Michael H. <mw...@py...>]

Given SF's current attitude to anon CVS, is it possible to make
available snapshots of the state of CVS semi-regularly?

Cheers,
M.

-- 
  ARTHUR:  Don't ask me how it works or I'll start to whimper.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11

[Pyobjc-dev] PyShellView?

[Michael H. <mw...@py...>]

I seem to have written this on the train on the way back from
EuroPython:

For a PyObjC application I want to write, I really really want to have
a Python shell view, i.e. an area I can type Python commands into and
have them executed interactively.  I should have few problems with the
Python side -- I seem to do things like this all the time -- but the
Cocoa side is considerably more mysterious to me.

Also I want to donate this to the PyObjC project, as it would be an
essential component of any PyObjC-based IDE, and I would like to do a
really good job and produce a widget that is maintainable by others.

I imagine this would involve writing a subclass of NSTextView.
Override keyDown:?  I'm not sure where to hook into to modify
behaviour at this level.

In dreamland, I would like to be able to drag a PyShellView from the
palette in IB, select which module it should run in from the Info
window -- default "__main__" -- and have things Just Work(tm).

I don't really have any time to work on this, but probably will find
some anyway.

Comments?

Cheers,
M.

-- 
  Two things I learned for sure during a particularly intense acid
  trip in my own lost youth: (1) everything is a trivial special case
  of something else; and, (2) death is a bunch of blue spheres.
                                             -- Tim Peters, 1 May 1998

Re: [Pyobjc-dev] HelloWorld.py segfaults

[b.bum <bb...@ma...>]

On Monday, June 30, 2003, at 5:27 AM, Just van Rossum wrote:
> It doesn't. (It seems that delegates are not retained in general.)

Correct.

In general, delegates, observers, outlets and other "informal" 
connections between objects are not retained-- they are "weak 
references".   Unfortunately, a weak reference in Objective-C is more 
or less an invitation for your app to crash when you didn't expect it 
to -- I have never agreed with the decision to use this implementation 
pattern nor have I ever seen a reasonable explanation as to why such a 
choice was made.

Claims that doing so makes memory management easier are bogus.  Given 
the number of apps that have shipped such that closing a document leads 
to a crasher at some later time (most likely because a notification was 
sent to a deceased observer), this has clearly caused a lot of hell in 
the development community.  I would rather see apps that leak slightly 
than apps that crash at random because of retain/release issues.   
Leaks are much easier to fix than the latter.

Garbage collection is not an excuse for lazy coding.  You always have 
to clean up after yourself!

b.bum

Re: [Pyobjc-dev] HelloWorld.py segfaults

[Just v. R. <ju...@le...>]

Chris Ryland wrote:

> Uh-oh--can you explain to the uninitiates why these two code sequences  
> aren't identical?

(Cleaning up the code sequences a little bit)

    #1:
    app.setDelegate_(AppDelegate.alloc().init())

vs.

    #2:
    delegate = AppDelegate.alloc().init()
    app.setDelegate_(delegate)

This is pretty messy, but IMO that's not PyObjC's fault. PyObjC makes
sure that Python's refcounting is synchronized with ObjC's, meaning that
if you do

    x = SomeObject.alloc().init()

there is exactly one reference to the created instance: the variable
'x'. If 'x' goes out of scope, the value it's pointing to goes away.

Code snippet #1 creates an object, passes that to setDelegate_(). The
app object stores a pointer to the new instances. Normally storing a
pointer means the reference count is incremented (the object is
"retained" in ObjC terms). In pure Python, it is guaranteed this will
happen. Cocoa on the other hand has quite a few places where it uses
what I call a poor man's weak reference scheme, meaning it will store a
pointer *without* incrementing the reference count. This is to avoid
references cycles (in any straight refcounting scheme, cycles cause
leaks unless the cycles are explicitly broken). So what happens in
snippet #1 is that the app object stores a pointer, but the instance
will be freed by Python when setDelegate_() returns; after all, there
are no hard references to it anymore! So we have a stale pointer,
causing a crash.

Snippet #2 works around this by sticking the object in a (local)
variable, ensuring the object stays around as long as the variable is in
scope. Since the event loop is run in the same function, this is long
enough.

Using a variable is just one way to work around the problem, the other
one is to simply call .retain() on the delegate object, "artificially"
increasing the reference count, creating a leak on purpose. That's ok,
since the app delegate is supposed to be alive for the lifetime of the
app anyway.

The real solution however, is to use Interface Builder.

It should be quite rare you have to worry about this: most of the time
when Cocoa uses these "weak references", it is guaranteed the references
object is alive long enough. For example _usually_ you'll instantiate
your app delegate in your main nib file and assign it as the delegate of
the app there (by means of an outlet connection). A weak reference is
still used (as is actually the case with outlets in general!), but you
don't have to be aware of it since Cocoa will automatically do the right
thing. It's only when you manyally work with delegates (or rather,
outlets in general) you sometimes come across this problem.

Just

Re: [Pyobjc-dev] HelloWorld.py segfaults

[Jack J. <Jac...@cw...>]

On Monday, Jun 30, 2003, at 15:42 Europe/Amsterdam, Chris Ryland wrote:

>>> If you change the code to:
>>>   dgate = AppDelegate.alloc().init()
>>>       NSApp.setDelegate_(dgate)
>>>
>>> instead of 'NSApp.setDelegate_(AppDelegate.alloc().init())' the
>>> example works as expected.
> Uh-oh--can you explain to the uninitiates why these two code sequences 
> aren't identical?

It's a refcounting issue. The variation with the "dgate" helper 
variable will keep the AppDelegate alive at least as long as the 
"dgate" variable exists, which is until the end of the program.

The other variation would be identical if setDelegate_ was normal 
Python code (the refcount of the AppDelegate would be one lower, but 
still greater than zero). But ObjC refcounting works different than 
Python refcounting, and while usually the differences are not 
noticeable there are some exceptions. Apparently delegates are one such 
exceptions: the receiving class (NSApp) does not increment the refcount 
on its delegate. Therefore, when setDelegate_() returns the refcount on 
the AppDelegate will be decremented to zero, and the object will be 
garbage collected.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman