Re: [Factor-talk] Factor on OS X El Capitan broken?
I'm not sure why the permissions got broken. It should work now though. On Thu, Oct 1, 2015 at 9:08 PM, John Benediktsson wrote: > Sorry, looks like a permissions error on the downloads server. > > Hopefully we can get that resolved soon. > > El Capitan introduced a GL Error that was not on previous OS X versions. > We have patched the latest code, but if you'd like to get your 0.97 > working, you can apply this fix: > > > https://github.com/slavapestov/factor/commit/9d021bb0817d3a1603519d36bc885f31e736d491 > > Or, bootstrap from the latest development version. > > $ git clone git://factorcode.org/git/factor.git > $ cd factor > $ build-support/factor.sh update > > > > > > > On Thu, Oct 1, 2015 at 8:05 PM, Sankaranarayanan Viswanathan < > rationalrev...@gmail.com> wrote: > >> I tried re-downloading factor-macosx-x86-64-0.97.dmg from the >> factorcode.org site, but that shows the same problem. I then tried the >> development release links for OS X, but those links seem broken. I >> have yet to attempt to build from source.. >> >> >> >> -- >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> > > > > -- > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor on OS X El Capitan broken?
Sorry, looks like a permissions error on the downloads server. Hopefully we can get that resolved soon. El Capitan introduced a GL Error that was not on previous OS X versions. We have patched the latest code, but if you'd like to get your 0.97 working, you can apply this fix: https://github.com/slavapestov/factor/commit/9d021bb0817d3a1603519d36bc885f31e736d491 Or, bootstrap from the latest development version. $ git clone git://factorcode.org/git/factor.git $ cd factor $ build-support/factor.sh update On Thu, Oct 1, 2015 at 8:05 PM, Sankaranarayanan Viswanathan < rationalrev...@gmail.com> wrote: > I tried re-downloading factor-macosx-x86-64-0.97.dmg from the > factorcode.org site, but that shows the same problem. I then tried the > development release links for OS X, but those links seem broken. I > have yet to attempt to build from source.. > > > > -- > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor on OS X El Capitan broken?
I tried re-downloading factor-macosx-x86-64-0.97.dmg from the factorcode.org site, but that shows the same problem. I then tried the development release links for OS X, but those links seem broken. I have yet to attempt to build from source.. -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor on OS X El Capitan broken?
Try the latest one.
On Thu, Oct 1, 2015, 19:30 Sankaranarayanan Viswanathan <
rationalrev...@gmail.com> wrote:
> Hello,
>
> I just upgraded my macbook to El Capitan today, and the opening the
> factor help browser seems broken. I get the message:
>
> An error occurred while drawing the world T{ world f ~array~ ~array~ f
> f ~vector~ ~array~ ~debugger~ t t f This world has been
> deactivated to prevent cascading errors. gl-error-tuple function f
> code 1286 string "Invalid framebuffer operation"
>
> Wondering if there's a newer binary for OS X?
>
> Thanks,
> Sankar
>
>
>
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Factor on OS X El Capitan broken?
Hello,
I just upgraded my macbook to El Capitan today, and the opening the
factor help browser seems broken. I get the message:
An error occurred while drawing the world T{ world f ~array~ ~array~ f
f ~vector~ ~array~ ~debugger~ t t f This world has been
deactivated to prevent cascading errors. gl-error-tuple function f
code 1286 string "Invalid framebuffer operation"
Wondering if there's a newer binary for OS X?
Thanks,
Sankar
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Ctrl+Break
Hello! You could have that as a library function, not necessarily written in Factor. The Listener already catches and handles all exceptions raised by running user code, am I right? 02.10.2015, 00:19, "John Benediktsson" : > you can open another listener and suspend the thread of the first > > we don't have a way to kill threads: > > https://github.com/slavapestov/factor/issues/1387 > > or wait/join threads: > > https://github.com/slavapestov/factor/issues/1407 > > On Thu, Oct 1, 2015 at 2:12 PM, Alexander Ilin wrote: >> Hello! >> >> 01.10.2015, 22:33, "HP wei" : >>> I try to hit Control-C but it continues to run. >>> *** How to exit a running words ? >> >> HP wei raises a very good point. Is there a way to interrupt an infinite >> loop or a long-running word? >> >> If such a mechanism is not there in Factor UI, I could share a way to >> implement it (Windows-specific). >> >> It involves running a native background thread with the Ctrl+Break hotkey >> globally hooked. When the hotkey is triggered, the main thread is >> interrupted by setting its exception flag. All words running from the >> Scratchpad should expect this special kind of exception. I'm not too good >> with Factor yet, so I could not implement this without some serious >> help/pointers, but I can share the details of the same mechanism implemented >> elsewhere (an open-source run-time environment). >> >> ---=--- >> Александр >> >> -- >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk > , > > -- > , > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk ---=--- Александр -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Ctrl+Break
you can open another listener and suspend the thread of the first we don't have a way to kill threads: https://github.com/slavapestov/factor/issues/1387 or wait/join threads: https://github.com/slavapestov/factor/issues/1407 On Thu, Oct 1, 2015 at 2:12 PM, Alexander Ilin wrote: > Hello! > > 01.10.2015, 22:33, "HP wei" : > > I try to hit Control-C but it continues to run. > > *** How to exit a running words ? > > HP wei raises a very good point. Is there a way to interrupt an infinite > loop or a long-running word? > > If such a mechanism is not there in Factor UI, I could share a way to > implement it (Windows-specific). > > It involves running a native background thread with the Ctrl+Break > hotkey globally hooked. When the hotkey is triggered, the main thread is > interrupted by setting its exception flag. All words running from the > Scratchpad should expect this special kind of exception. I'm not too good > with Factor yet, so I could not implement this without some serious > help/pointers, but I can share the details of the same mechanism > implemented elsewhere (an open-source run-time environment). > > ---=--- > Александр > > > -- > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Ctrl+Break
Hello! 01.10.2015, 22:33, "HP wei" : > I try to hit Control-C but it continues to run. > *** How to exit a running words ? HP wei raises a very good point. Is there a way to interrupt an infinite loop or a long-running word? If such a mechanism is not there in Factor UI, I could share a way to implement it (Windows-specific). It involves running a native background thread with the Ctrl+Break hotkey globally hooked. When the hotkey is triggered, the main thread is interrupted by setting its exception flag. All words running from the Scratchpad should expect this special kind of exception. I'm not too good with Factor yet, so I could not implement this without some serious help/pointers, but I can share the details of the same mechanism implemented elsewhere (an open-source run-time environment). ---=--- Александр -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] potential memory issue --- Fwd: how to error trapping 'link-info'
You can run your code in the leaks combinator and it will show you what
leaked. I suspect that you're just using a lot of memory though.
[ { 1 2 3 } [ malloc drop ] each ] leaks members .
{ ~malloc-ptr~ ~malloc-ptr~ ~malloc-ptr~ }
On Thu, Oct 1, 2015 at 12:31 PM, HP wei wrote:
> Yes, I could find out a bit more about the memory issue.
>
> I tried it again this afternoon. After 50 minutes into the action
> 0 "path" t [ link-info ... ] each-file
> the system 'top' shows RES rises above 1.2GB and %MEM becomes 15.7%
> and they continue to rise.
> It blacks out the gui window of factor.
>
> I try to hit Control-C but it continues to run.
> *** How to exit a running words ?
>
> It looks like the only natural way I know of to 'stop' it is to wait for
> link-info to hit the missing file scenario --- like the overnight run of
> last night.
>
> So, I just killed the factor session from the shell. And missed the
> opportunity
> to inspect the memory usage in factor, as John suggested.
>
> Is there a way to exit running words ?
> [ perhaps, I need to learn to use a factor-debugger ? ]
>
> -
>
> Replying to John's questions about the disk layout:
>it is a disk with a tree of directories.
>directory count ~ 6000
>total number of files as of now ~ 1.1 million
>total number of softlinks ~ 57
>total file size ~ 70GB
>
>number of files in each sub-directory (not including the files in
> sub-directory inside it)
>range from a few hundreds to as high as of the order of <~10K.
>
>Some of the directories are constantly updated throughout the day.
>
> --HP
>
>
>
> On Thu, Oct 1, 2015 at 12:27 PM, John Benediktsson
> wrote:
>
>> Maybe you can debug a little if you see that happen again?
>>
>> Perhaps something like this to get the largest number of instances, if
>> there is a per-file leak:
>>
>> IN: scratchpad all-instances [ class-of ] histogram-by
>> sort-values reverse 10 head .
>>
>> Some other words for inspecting memory:
>>
>> http://docs.factorcode.org/content/article-tools.memory.html
>>
>> Can you give us some information about your disk layout?
>>
>> Is it one big directory with 1 million files? Is it a tree of
>> directories? What do you think is average number of files per-directory?
>>
>> I opened a bug report if you'd like to provide feedback there rather than
>> the mailing list:
>>
>> https://github.com/slavapestov/factor/issues/1483
>>
>>
>>
>>
>> On Thu, Oct 1, 2015 at 8:38 AM, HP wei wrote:
>>
>>> Well, I just checked the running factor session that failed the
>>> task overnight that I mentioned in below email.
>>>
>>> From the linux system command 'top',
>>> I see that this particular factor is using
>>> VIRT 4.0g
>>> RES 2.0g
>>> %MEM 26%
>>>
>>> I clicked on the restart listener button and the numbers remain the same.
>>> should I have done more to clean up the memory usage ?
>>>
>>> --
>>>
>>> For comparison, I killed the factor session and restart it from the
>>> shell.
>>> The numbers are
>>> VIRT 940M
>>> RES 182M
>>> %MEM 2.2%
>>>
>>> ==> Had the factor continued to run last night,
>>>it would have probably exhausted the memory on the machine.
>>>I guess there might be some memory (leak) issue somewhere ???
>>>
>>> --HP
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From: HP wei
>>> Date: Thu, Oct 1, 2015 at 9:36 AM
>>> Subject: how to error trapping 'link-info'
>>> To: factor-talk@lists.sourceforge.net
>>>
>>>
>>> As suggested by John, I test out the following action to
>>> get the total file sizes of a disk volume.
>>>
>>> 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [
>>> size>> + ] if ] each-file
>>>
>>>
>>> Our big-folder is on a netapp server shared by tens of people. Many
>>> small files get updated
>>> every minutes if not seconds. The update may involve removing the file
>>> first.
>>> It has many many subfolders which in turn have more subfolders.
>>> Each subfolder may have hundreds of files (occasionally in the
>>> thousands).
>>>
>>> After a few day's discussion with factor guru's, I understand that
>>> each-file traverses the directory structure by first putting
>>> entries of a folder in a sequence. And it processes each entry one by
>>> one.
>>> Although this may not cause using big chunk of memory at a time,
>>> it does have the following issue..
>>>
>>>
>>>
>>> Last night, I left the command running and came back this morning to find
>>> that it failed with the message.
>>> lstat: "a path to a file" does not exist !!!
>>>
>>> This is because after 'each-file' puts the file into the sequence and
>>> then when
>>> it is its turn to be processed, it is not there at the time!!
>>> Without error trapping, the above "0 ... each-file" could not work in
>>> our case.
>>>
>>> So, I guess I would need to do error-trapping on the word link-info.
>>> I do not know how to do it
Re: [Factor-talk] potential memory issue --- Fwd: how to error trapping 'link-info'
Yes, I could find out a bit more about the memory issue. I tried it again this afternoon. After 50 minutes into the action 0 "path" t [ link-info ... ] each-file the system 'top' shows RES rises above 1.2GB and %MEM becomes 15.7% and they continue to rise. It blacks out the gui window of factor. I try to hit Control-C but it continues to run. *** How to exit a running words ? It looks like the only natural way I know of to 'stop' it is to wait for link-info to hit the missing file scenario --- like the overnight run of last night. So, I just killed the factor session from the shell. And missed the opportunity to inspect the memory usage in factor, as John suggested. Is there a way to exit running words ? [ perhaps, I need to learn to use a factor-debugger ? ] - Replying to John's questions about the disk layout: it is a disk with a tree of directories. directory count ~ 6000 total number of files as of now ~ 1.1 million total number of softlinks ~ 57 total file size ~ 70GB number of files in each sub-directory (not including the files in sub-directory inside it) range from a few hundreds to as high as of the order of <~10K. Some of the directories are constantly updated throughout the day. --HP On Thu, Oct 1, 2015 at 12:27 PM, John Benediktsson wrote: > Maybe you can debug a little if you see that happen again? > > Perhaps something like this to get the largest number of instances, if > there is a per-file leak: > > IN: scratchpad all-instances [ class-of ] histogram-by > sort-values reverse 10 head . > > Some other words for inspecting memory: > > http://docs.factorcode.org/content/article-tools.memory.html > > Can you give us some information about your disk layout? > > Is it one big directory with 1 million files? Is it a tree of > directories? What do you think is average number of files per-directory? > > I opened a bug report if you'd like to provide feedback there rather than > the mailing list: > > https://github.com/slavapestov/factor/issues/1483 > > > > > On Thu, Oct 1, 2015 at 8:38 AM, HP wei wrote: > >> Well, I just checked the running factor session that failed the >> task overnight that I mentioned in below email. >> >> From the linux system command 'top', >> I see that this particular factor is using >> VIRT 4.0g >> RES 2.0g >> %MEM 26% >> >> I clicked on the restart listener button and the numbers remain the same. >> should I have done more to clean up the memory usage ? >> >> -- >> >> For comparison, I killed the factor session and restart it from the shell. >> The numbers are >> VIRT 940M >> RES 182M >> %MEM 2.2% >> >> ==> Had the factor continued to run last night, >>it would have probably exhausted the memory on the machine. >>I guess there might be some memory (leak) issue somewhere ??? >> >> --HP >> >> >> >> -- Forwarded message -- >> From: HP wei >> Date: Thu, Oct 1, 2015 at 9:36 AM >> Subject: how to error trapping 'link-info' >> To: factor-talk@lists.sourceforge.net >> >> >> As suggested by John, I test out the following action to >> get the total file sizes of a disk volume. >> >> 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [ size>> >> + ] if ] each-file >> >> >> Our big-folder is on a netapp server shared by tens of people. Many small >> files get updated >> every minutes if not seconds. The update may involve removing the file >> first. >> It has many many subfolders which in turn have more subfolders. >> Each subfolder may have hundreds of files (occasionally in the thousands). >> >> After a few day's discussion with factor guru's, I understand that >> each-file traverses the directory structure by first putting >> entries of a folder in a sequence. And it processes each entry one by one. >> Although this may not cause using big chunk of memory at a time, >> it does have the following issue.. >> >> >> >> Last night, I left the command running and came back this morning to find >> that it failed with the message. >> lstat: "a path to a file" does not exist !!! >> >> This is because after 'each-file' puts the file into the sequence and >> then when >> it is its turn to be processed, it is not there at the time!! >> Without error trapping, the above "0 ... each-file" could not work in >> our case. >> >> So, I guess I would need to do error-trapping on the word link-info. >> I do not know how to do it. Any hint ? >> >> Thanks >> HP >> >> >> >> >> -- >> >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> >> > > > -- > > ___ > Factor-talk m
Re: [Factor-talk] potential memory issue --- Fwd: how to error trapping 'link-info'
Maybe you can debug a little if you see that happen again? Perhaps something like this to get the largest number of instances, if there is a per-file leak: IN: scratchpad all-instances [ class-of ] histogram-by sort-values reverse 10 head . Some other words for inspecting memory: http://docs.factorcode.org/content/article-tools.memory.html Can you give us some information about your disk layout? Is it one big directory with 1 million files? Is it a tree of directories? What do you think is average number of files per-directory? I opened a bug report if you'd like to provide feedback there rather than the mailing list: https://github.com/slavapestov/factor/issues/1483 On Thu, Oct 1, 2015 at 8:38 AM, HP wei wrote: > Well, I just checked the running factor session that failed the > task overnight that I mentioned in below email. > > From the linux system command 'top', > I see that this particular factor is using > VIRT 4.0g > RES 2.0g > %MEM 26% > > I clicked on the restart listener button and the numbers remain the same. > should I have done more to clean up the memory usage ? > > -- > > For comparison, I killed the factor session and restart it from the shell. > The numbers are > VIRT 940M > RES 182M > %MEM 2.2% > > ==> Had the factor continued to run last night, >it would have probably exhausted the memory on the machine. >I guess there might be some memory (leak) issue somewhere ??? > > --HP > > > > -- Forwarded message -- > From: HP wei > Date: Thu, Oct 1, 2015 at 9:36 AM > Subject: how to error trapping 'link-info' > To: factor-talk@lists.sourceforge.net > > > As suggested by John, I test out the following action to > get the total file sizes of a disk volume. > > 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [ size>> > + ] if ] each-file > > > Our big-folder is on a netapp server shared by tens of people. Many small > files get updated > every minutes if not seconds. The update may involve removing the file > first. > It has many many subfolders which in turn have more subfolders. > Each subfolder may have hundreds of files (occasionally in the thousands). > > After a few day's discussion with factor guru's, I understand that > each-file traverses the directory structure by first putting > entries of a folder in a sequence. And it processes each entry one by one. > Although this may not cause using big chunk of memory at a time, > it does have the following issue.. > > > > Last night, I left the command running and came back this morning to find > that it failed with the message. > lstat: "a path to a file" does not exist !!! > > This is because after 'each-file' puts the file into the sequence and then > when > it is its turn to be processed, it is not there at the time!! > Without error trapping, the above "0 ... each-file" could not work in our > case. > > So, I guess I would need to do error-trapping on the word link-info. > I do not know how to do it. Any hint ? > > Thanks > HP > > > > > -- > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] potential memory issue --- Fwd: how to error trapping 'link-info'
Well, I just checked the running factor session that failed the task overnight that I mentioned in below email. >From the linux system command 'top', I see that this particular factor is using VIRT 4.0g RES 2.0g %MEM 26% I clicked on the restart listener button and the numbers remain the same. should I have done more to clean up the memory usage ? -- For comparison, I killed the factor session and restart it from the shell. The numbers are VIRT 940M RES 182M %MEM 2.2% ==> Had the factor continued to run last night, it would have probably exhausted the memory on the machine. I guess there might be some memory (leak) issue somewhere ??? --HP -- Forwarded message -- From: HP wei Date: Thu, Oct 1, 2015 at 9:36 AM Subject: how to error trapping 'link-info' To: factor-talk@lists.sourceforge.net As suggested by John, I test out the following action to get the total file sizes of a disk volume. 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [ size>> + ] if ] each-file Our big-folder is on a netapp server shared by tens of people. Many small files get updated every minutes if not seconds. The update may involve removing the file first. It has many many subfolders which in turn have more subfolders. Each subfolder may have hundreds of files (occasionally in the thousands). After a few day's discussion with factor guru's, I understand that each-file traverses the directory structure by first putting entries of a folder in a sequence. And it processes each entry one by one. Although this may not cause using big chunk of memory at a time, it does have the following issue.. Last night, I left the command running and came back this morning to find that it failed with the message. lstat: "a path to a file" does not exist !!! This is because after 'each-file' puts the file into the sequence and then when it is its turn to be processed, it is not there at the time!! Without error trapping, the above "0 ... each-file" could not work in our case. So, I guess I would need to do error-trapping on the word link-info. I do not know how to do it. Any hint ? Thanks HP -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Fwd: how to error trapping 'link-info'
The equivalent would be: [ link-info dup symbolic-link? [ drop ] [ size>> + ] if ] [ drop ] recover On Thu, Oct 1, 2015 at 6:54 AM, HP wei wrote: > Just want to elaborate on what I meant by 'error trapping' link-info. > > [ link-info dup symbolic-link? [ drop ] [ size>> + ] > > In python's syntax, I would write the above quot as something like: > > try: > file_info = link_info(dir_entry) > if not is_symbolic_link(file_info): > total_size += get_fize(file_info) > except: > pass > > continue > > > HP > > > > > > -- Forwarded message -- > From: HP wei > Date: Thu, Oct 1, 2015 at 9:36 AM > Subject: how to error trapping 'link-info' > To: factor-talk@lists.sourceforge.net > > > As suggested by John, I test out the following action to > get the total file sizes of a disk volume. > > 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [ size>> > + ] if ] each-file > > > Our big-folder is on a netapp server shared by tens of people. Many small > files get updated > every minutes if not seconds. The update may involve removing the file > first. > It has many many subfolders which in turn have more subfolders. > Each subfolder may have hundreds of files (occasionally in the thousands). > > After a few day's discussion with factor guru's, I understand that > each-file traverses the directory structure by first putting > entries of a folder in a sequence. And it processes each entry one by one. > Although this may not cause using big chunk of memory at a time, > it does have the following issue.. > > > > Last night, I left the command running and came back this morning to find > that it failed with the message. > lstat: "a path to a file" does not exist !!! > > This is because after 'each-file' puts the file into the sequence and then > when > it is its turn to be processed, it is not there at the time!! > Without error trapping, the above "0 ... each-file" could not work in our > case. > > So, I guess I would need to do error-trapping on the word link-info. > I do not know how to do it. Any hint ? > > Thanks > HP > > > > > -- > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] remote listener over tcp
We have support for that in our FUEL package for emacs. Probably it could be factored (ahem) out, but this is how you can do it, starting on port 9000: IN: scratchpad USE: fuel.remote IN: scratchpad 9000 fuel-start-remote-listener Then somewhere else: $ telnet machine 9000 On Thu, Oct 1, 2015 at 7:46 AM, HP wei wrote: > The objective: > we have several linux machines that I need to check on certain > status (--- disks, update-jobs etc). > My plan is, if feasible, to run a remote factor-listener on each of > those > machines and run a 'master' factor on a machine that collects all info > and presents issues on a gui-window. > > On the master machine, if I find an issue that needs to be addressed > on machine-A, I will need to issue a command from the master > machine gui-window and that command shall be send to machine-A to be > executed. [ The command may be a linux system commad >or a custom command written by C++ >or perhaps something written by factor, if > appropriate. ] > > e.g. initially, > I will have a word called 'check-disks'. > And the master can send the word over tcp to each of those machines > and collect report. > > Eventually, each machine will do the checking regularly and send > issues back to the master. > > > > The first step appears to be learning how to set up a remote listener over > tcp > and talk to it from a master machine. > > Could you please direct me to a place where someone has written something > about > how to this in factor ?? A working example will be nice. > > thanks > HP > > > > -- > > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] remote listener over tcp
The objective: we have several linux machines that I need to check on certain status (--- disks, update-jobs etc). My plan is, if feasible, to run a remote factor-listener on each of those machines and run a 'master' factor on a machine that collects all info and presents issues on a gui-window. On the master machine, if I find an issue that needs to be addressed on machine-A, I will need to issue a command from the master machine gui-window and that command shall be send to machine-A to be executed. [ The command may be a linux system commad or a custom command written by C++ or perhaps something written by factor, if appropriate. ] e.g. initially, I will have a word called 'check-disks'. And the master can send the word over tcp to each of those machines and collect report. Eventually, each machine will do the checking regularly and send issues back to the master. The first step appears to be learning how to set up a remote listener over tcp and talk to it from a master machine. Could you please direct me to a place where someone has written something about how to this in factor ?? A working example will be nice. thanks HP -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Fwd: how to error trapping 'link-info'
Just want to elaborate on what I meant by 'error trapping' link-info. [ link-info dup symbolic-link? [ drop ] [ size>> + ] In python's syntax, I would write the above quot as something like: try: file_info = link_info(dir_entry) if not is_symbolic_link(file_info): total_size += get_fize(file_info) except: pass continue HP -- Forwarded message -- From: HP wei Date: Thu, Oct 1, 2015 at 9:36 AM Subject: how to error trapping 'link-info' To: factor-talk@lists.sourceforge.net As suggested by John, I test out the following action to get the total file sizes of a disk volume. 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [ size>> + ] if ] each-file Our big-folder is on a netapp server shared by tens of people. Many small files get updated every minutes if not seconds. The update may involve removing the file first. It has many many subfolders which in turn have more subfolders. Each subfolder may have hundreds of files (occasionally in the thousands). After a few day's discussion with factor guru's, I understand that each-file traverses the directory structure by first putting entries of a folder in a sequence. And it processes each entry one by one. Although this may not cause using big chunk of memory at a time, it does have the following issue.. Last night, I left the command running and came back this morning to find that it failed with the message. lstat: "a path to a file" does not exist !!! This is because after 'each-file' puts the file into the sequence and then when it is its turn to be processed, it is not there at the time!! Without error trapping, the above "0 ... each-file" could not work in our case. So, I guess I would need to do error-trapping on the word link-info. I do not know how to do it. Any hint ? Thanks HP -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] how to error trapping 'link-info'
As suggested by John, I test out the following action to get the total file sizes of a disk volume. 0 "a_path_to_big_folder" [ link-info dup symbolic-link? [ drop ] [ size>> + ] if ] each-file Our big-folder is on a netapp server shared by tens of people. Many small files get updated every minutes if not seconds. The update may involve removing the file first. It has many many subfolders which in turn have more subfolders. Each subfolder may have hundreds of files (occasionally in the thousands). After a few day's discussion with factor guru's, I understand that each-file traverses the directory structure by first putting entries of a folder in a sequence. And it processes each entry one by one. Although this may not cause using big chunk of memory at a time, it does have the following issue.. Last night, I left the command running and came back this morning to find that it failed with the message. lstat: "a path to a file" does not exist !!! This is because after 'each-file' puts the file into the sequence and then when it is its turn to be processed, it is not there at the time!! Without error trapping, the above "0 ... each-file" could not work in our case. So, I guess I would need to do error-trapping on the word link-info. I do not know how to do it. Any hint ? Thanks HP -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] A bug ?
2015-10-01 8:47 GMT+02:00 HP Wei :
> Thanks for suggesting to look at the source of (directory-entries)
>
> I see that the iterator over a directory is the word: with-unix-directory
> and (directory-entries) uses produce to collect the entries into a sequence.
>
> I did not find a word in sequences that is similar to produce but does a
> ‘reduce’ action
> — sot that I could simply replace ‘produce’ in the definition of
> (directory-entries).
You can do it like this:
USING: accessors alien.strings classes.struct combinators
continuations io.backend io.directories.unix io.files.info kernel math
sequences unix.ffi ;
FROM: io.directories.unix.linux => next-dirent ;
IN: examples.sequences
DEFER: directory-size
: entry-size-file ( name -- size )
file-info size>> ;
: entry-size-dir ( name -- size )
dup { "." ".." } member? [ drop 0 ] [
normalize-path directory-size
] if ;
: entry-size ( dirent* -- size )
[ d_name>> alien>native-string ] [ d_type>> ] bi {
{ DT_REG [ entry-size-file ] }
{ DT_DIR [ entry-size-dir ] }
[ 2drop 0 ]
} case ;
: dirent-size ( unix-dir dirent -- size/f )
next-dirent [ entry-size ] [ drop f ] if ;
: (directory-size) ( unix-dir dirent -- total )
2dup dirent-size [ -rot (directory-size) + ] [ 2drop 0 ] if* ;
: directory-size ( path -- total )
[
[ dirent (directory-size) ] with-unix-directory
] [ 2drop 0 ] recover ;
The code gets a little tricky because you didn't want to ever load a
full directory listing into memory.
--
mvh/best regards Björn Lindqvist
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
