#114 (IMAP server password stored in plain text on disk) - POPFile - Automatic Email Classification - Trac

Trying POPfile - yay!



Saw this developer response, dated 1909. Scary!

#114 (IMAP server password stored in plain text on disk) - POPFile - Automatic Email Classification - Trac: "I just don't see how any kind of encryption of the password would be more than just cosmetic."

Checking:



It is still world readable by default (on my Mac).

Well, it is no longer plaintext, but I am not sure how good the crypto is.



(It's Open Source, so I will put this on my list of things to do.)

Email Classification Automation with Exchange - Microsoft Exchange - Spiceworks

Soam advocate?

Email Classification Automation with Exchange - Microsoft Exchange - Spiceworks: "Email classification is usually in the providence of the sender not the receiver, as its the sender's data thats being transferred."
'via Blog this'

Automatic Email Sorting/Classification in Outlook? - Ars Technica OpenForum

I wish:

Automatic Email Sorting/Classification in Outlook? - Ars Technica OpenForum: "automatic sorting in Outlook"
'via Blog this'

Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?

Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?: "For some operations, prefix notation just reads better than postfix — prefix (and infix!) operations have a long tradition in mathematics which likes notations where the visuals help the mathematician thinking about a problem. "

Semi-agreement.



I like readable and familiar notations.  I like notations familiar from math.



But I note that math also has postfix notations, such as factorial n!. Double factorial or involutions n!!. n# - commonly product of primes up to n. I argue that % is a postfix operator (that divides by 100).



And how about situations where the operator symbols surround their arguments: absolute value and cardinality |a|.  Also the open/closed interval notations (lo,hi) [lo,hi] [lo,hi).  Let alone ]a,b(, etc.



Arguably the complement of a set A^C is a postfix operator - but really is is a superscript operator.) Math also makes great use of two dimensions, subscripts and subscripts, both to left and right.  (









Myself, I prefer the approach - I think it was Algol-68 - where an operator could be applied both prefix or postfix (and occasionally infix, and other fixes).



To apply a function f to an argument value x, write



    prefix

f :- x

    postfix

x -: f

Above I have used :- and -: as my function apply operators, deliberately using unfamiliar notation. Familiar notation might be

f . x

or simply putting things next to each other

f x

in published math, usually in different fonts (which are essentially a type system).





To apply a function f to an argument list (x,y), write



   prefix

f :- (x,y)

   postfix

(x,y) -: f

    infix

x --: f :-- y

To apply a function f to an argument list (x,y,z,...), write



   prefix

f :- (x,y,z,...)

I myself don't like SmallTalk or AppleTalk like polyfix

f: x: xval y: yval z: zval

at least not beyond keyword parameters

f :- (x=xval, y=yval, z=zval, ...)

 With the usual elision and shortenings



   prefix

f :- x  

==> f. x 

==> f of x 

==> f(x) 

    postfix

x -: f 

==> x's f

===> x | f    (stretching to use a UNIX-like pipe notation) 

    infix

x --: f :-- y 

==> x .f. y

===> x .+. y 

==> x + y     (if the operator f or + is syntactically defined to be infix) 

I suppose that allowing different *fixes for the same function goes against Python's "there should be only one way to do it" philosophy.

I like Python's brevity

I like Python's brevity.



?



Actually, I like Python's use of indentation.  It makes the code more readable.  It closely corresponds to how many people write pseudocode on paper.  (Now, if the code could only contain vertical bars down the left, the number of which indicate the nesting level.  Hmm, I wonder



In most respects, Python is NOT a language of brevity.   Python code is often verbose.



But the use of indentation is elegant and reduces clutter.



(Perl's sigils? clutter!)









I am amused that Python3 is increasing the amount of syntactic clutter, by requiring parentheses around the arguments to print - print("a") versus pythin2 print "a".



It's a pity that Python3 could not figure out a way to allow function calls without ()s.

less than function Block scope in Python

:-(

Block scope in Python - Stack Overflow: "No, there is no [python] language support for creating block scope. The only means to create scope is functions, classes or modules."

Someone else goes on to say: "The idiomatic way in Python is to keep your functions short. If you think you need this, refactor your code! :) "

I could very much like Python - but whenever I try to use it, I run into things like this very quickly.

I like Python's use of indentation.

But I imagine that the reasoning runs like this:

• Python uses indentation and hence doesn't need {...} to provide blocks for constructs like IF, functions, etc.
• But since Python doesn't have {...} blocks, we have no way to provide lexial scope except for def: and class: and modules.
• "Who needs it anyway?" says the chorus of unimaginative twerps. "Just refactor".

So think about refactoring: you could introduce a function with def, and then call it immediately.  Must make sure tat the function cannot be called from elsewhere, but Python allowing local definitions (not-quite-closures) is sufficient for that. But that requires typing the name in twice.  

I have been doing the following in some python code:

statement1
statement2
if 1:
     statement3.1
     statement3.2
statement4

when I want to emphasize the relatedness of statements3.1 and 3.2.

The equivalent of 

statement1
statement2
{
     statement3.1
     statement3.2
}
statement4

in Perl or C.

(Amusingly, emacs often requires me if add an if(1) to the blocks {}.  It doesn't like indented "blocks in space".  After all, what crazy person would want to create lots of local blocks?)

I like indicating the relatedness.

Plus, if I need a temporary variable or to import a function, I like to be able to do so in the smallest scope possible.

Yes, it can be refactored to be a function that is immediately invoked.  But that is repetitive.


This explores aspects of one of my rules "The most important thing in programming is the ability to give something a name.  The second most important thing is to not be required to give something a name."

Python requires scopes to have names.   It fails the second most important test.



---


The obvious way to support scopes in an indentation oriented language like Python would be:

statement1
statement2
scope:
     statement3.1
     statement3.2
statement4

i.e. introduce a keyword "scope" or the like.

Wanted: portable labelmaker, USB charge, upload label and location to database

I just spent ... more time than I want to admit ... searching for the lost AC adapter for my label printer.

DYMO LabelManager 280D Label Maker:
Rechargeable Battery Pack
USB Cable
D1
Charging Adapter

Damn! You would think that if it has a USB port, it could be charged via USB!!!!

I can understand that it might not be possible to operate via USB, if the labelmaker thermal printer takes too much power during operation.  But at least it could charge the battery!



Here's a Product I Want:

• LabelMaker
• Battery powered
• USB
• to charge battery
• for data communication with a controlling device
• PREFERRED: to mobile device (cell phone, tablet)
• LESS PREFERRED: to PC (Windows/Mac/*x/..., desktop/laptop/...)

OPTIONAL: freestanding, with the sort of lousy membrane keyboard that most label makers have.

ALTERNATE: use controlling device (cell phone, tablet, or PC) to write the label, etc.

• PREFERRED: cell phone and/or tablet
• Form factor of labelmaker such that it can easily be attached to mobile device.  
• E.g. clip over the edge of a cellphone, although that makes product specific to particular phones
• Myself, I would probably velcro it or otherwise attach it to my cellphone. 
• MUCH LESS PREFERRED: PC or laptop as controlling device for labelmaker
• Kills the usage model of composing and printing labels at storage shelves

Frankly, being able to write the label on a phone/tablet/laptop/PC is NOT a big selling point for me.  (Unless there is no keyboard on the labelmaker.)

Much more important to me would be having the ability to upload the text labels written and printed while walking around to a database.

I.e. PC--->LabelMaker or phone--->LabelMaker not important

LabelMaker ---> phone/PC/... is more important

USAGE MODEL: putting stuff away in storage. Print and label storage box or file, upload text of label (along with date and location) to a database.   So that you almost automatically get a database telling you WHERE you have stored a physical box or file.

Bonus points for allowing a photograph of what is being put away to be taken and recorded to the database.

The need to have location (GPS/other) and photo motivates having a labelmaker that is controlled by a mobile phone via USB or similar.  Plus, it gives you a much better input device than the lousy membrane keyboard typical of labelmakers.  Cost reduction for the labelmaker.

PlusPlus, if you have a need to download long lists of labels to print, phone/PC--->LabelMaker gives you that ability.

Location: GPS or wifi or or other usual wireless a start.   But if you want to record which room of a house or which shelf in a storage closet of an apartment you have put the box or file in, GPS not fine grain enough.   This partly motivates photographs - e.g. photograph a shelf, possibly with an ID number.  But it might also motivate something more convenient for user, such as RFID on shelves. Slightly more advanced tech, but more convenient. If you have home automation, e.g. for light switches, those IDs may be sufficient.

---

Further: standalone portable LabelMaker with wifi or other wireless - to update database immediately.  (Of course, it would need the usual lousy labelmaker keyboard, if not attached to a mobile phone.)

Is touch-typing no quicker than doing it with two fingers? | Money | The Guardian

Is touch-typing no quicker than doing it with two fingers? | Money | The Guardian:
"Is touch-typing no quicker than doing it with two fingers?
New research surprisingly suggests that untrained typists are often faster"
'via Blog this'

This makes me feel not so bad.



Nevertheless, I would like to learn how to touch type, because at times I have suffered from "computeritis" - typing and mousing related pain in hand/wrist shoulders.  One supposes that touch typing might distribute the load. (Although even that is questionable: some studies suggest that classic touch typing may worsen computeritis.)



(At the moment I have kept the computeritis at bay for a few years using a good keyboard (the Matias Mini Quiet Pro, with mechanical switches) with a good ergonomic setup (trackball, keyboard tray, etc.). I suspect that using non PC touchscreen devices may also have reduced the stress, although introducing different stressors.)

touch Device List

touch Device List: "GeChic On-Lap 1502 Ilitek, 10 Point, USB"

Learning the hard way that, although my GeChic external touchscreen display plugged into my MacBook and seemed to work, that the MacBook becomes unstable.

The video works fine.

The touch works at first - perhaps not the full multitouch that the GeChich is capable of, but at least in mouse emulation.

Unfortunately, after a few minutes - not even minutes of use, but minutes of just leaving it idle - whenever I touch the GeChic screen, the MacBook does a funny-not-quite-a-crash, with the upshot being that I am logged out and have to reenter my password to get back in.

It appears  that problems with touch on Macs are well known. “Touchscreens: iOS = Yes, OS X = No!"

The company Touch Base seems to have specialized in providing touch screen drivers for Macs, with a Unified Pointer Device Driver (UPDD).  Quite expensive. Like, 150$.  Well, at least the GeChic is on their supported touch device list.

Damn! I wish I had known this before wasting a few hours.  Strangely, many GeChic users report success with their Macs.

Knowing this does not excuse Apple's software.   If they do not support a device, she should say so - they should not support for a while, and then misbehave.

CONJECTURE: I think that the problem may be a I/O buffer overflow - not necessarily the "accessing memory beyond the limits specified by software", but the "too many I/O device inputs, the I/O buffer gets full and events have to be discarded, MacOS gives up after a while".

Why this suspicion?:  after I remove my finger from the GeChich touchscreen, the mouse cursor immediately goes to the upper right hand corner of the display, where it appears to "tremble".   I have seen that sort of thing with I/O devices that are constantly sending output, e.g. constantly reporting a position even when there has been no movement.

'via Blog this'

External touch screen | Apple

External touch screen | Apple:

---+ BOTTOM LINE:

I wasted a few hours trying to use my GeChic 1502I external touchscreen with my MacBook.

The video works, no drivers.

The touchscreen works at first.  But after a few minutes, any touch makes the MacBook do a funny not-quite-a-crash --- all screens go dark, and I have to re-log in.

---+ DETAIL:

I just connected my GeChic On-Lap 1502I 15.6" Full HD IPS Panel 10-point Projected Capacitive Portable Touchscreen Monitor to my MacBook Pro.


Why?  I wanted a touchscreen to run my "UIX ButtonPad" app.   


I had been using Duet Display to give me an external touchscreen for my MacBook using an iPad mini. Earlier the Quadro app on iPhone/iPad, which provides only the Button Pad functionality and is not a full external display.  But I wanted features missing in Quadro, so I wrote my own. Running it all on the laptop was easier than creating a hybrid app split between laptop and touchscreen phone or tablet. I can use a phone or tablet as an external touchscreen using remote display apps like Duet Display  or Avatron Air Display 


Duet Display  worked when it worked, but suffered problems like losing connections, especially when the iPad screen locked. I have my screen lockout time set very low, like 30 seconds.


+: Plus, I had this big external GeChic 1502I touchscreen, dating back to before I used Apple iPads and Duet Display. It's bigger than any iPad at the time of writing, even the 12.9" iPad Pro.


++, I really miss having a touchscreen device as my main laptop, so I will probably switch back to a Windows Surface, Surface Pro, or Surface Book.  And I wanted my UIX ButtonPad app to work when I give up on Apple MacBooks.


+++ I can supposedly use my Surface as an external touchscreen display for my MacBook.  (Haven't tried but software seems to be out there - VNC if nothing else.) Vice versa, although of course the MacBook isn't a touchscreen - but I can imagine Surface->MacBook->Duet->Tablet.


++++: Plus, I have several old Android tablets (freebies from company and techcons), and a few old Android phones.  I would like to be able to deploy touchscreen UIX ButtonPads onto these devices as well.


DISAPPOINTMENT: Due Display doesn't run on my old iPad Classic. Needs a more modern version of iOS.  Must investigate jailbreaking or XNU - otherwise these old IOS devices are just e-trash.


BOTTOM LINE: hybrid apps split across systems are a bit harder; remote display and touchscreen almost eliminate need.  (Hybrid apps might be more elegant than remote display. But first must code them up.  Hmm... I wonder if one could create a remote display app that could then be "locked" to run only a single app on that display?  Display-locked apps?  App-locked displays? I don't like limiting choice, but I can understand reducing interactions.)


PLEASANT SURPRISE:  I mainly wanted to use my UIX ButtonPad app on a touchscreen, but since Duet Display was acting up I found that it is actually quite pleasant to use on a non-touchscreen mouse and pointer system.  You park your mouse on your primary big button, and just click.  Not quite as pleasant as a touchscreen, but nicer than a WIMPy GUI on a big multi-display system. Possibilities in mapping keyboard shortcuts and mouse/trackball buttons to "big buttons" on the ButtonPad.


===


But...  I started this blog entry not to describe UIX ButtonPad, but to record notes about using external touchscreens like my GeChic 1502I on a Mac.  


My system: MacBook Pro 15" mid-2014, 16GB RAM, NVIDIA GeForce GT 750M 2048 MB). After connecting the GeChic, I have 3 external monitors:  30" NX-VUE30, 2560x1600, connected using HDMI; 24" Acer X243W, 1200x1920, connected by a USB display adapter (Diamond BVU195 DisplayLink); and the GeChic 1502I, 15", 1920x1080.   For a total of 4 displays, with the Retina display on the MacBook (2880x1800).  


(Even before the GeChic, I tried to have another 24" 1920x1200 display using a USB display adapter - however, this had major problems on the Mac (worked on Windows 7), so I gave up on *that* extra display.  Since the GeChic now works as a 3rd external display, I may revisit adding yet another 1920x1200 display, since I have several dating back to my last windows systems, before I switched to Apple, and before I started using 30" displays as my primary display rather than 24". Perhaps Apple has fixed their software - the problems were pretty obviously driver memory allocation.)


I have used this GeChic display frequently with Windows machines, with no problems. Obviously, there were problems, albeit minor, connecting it to the MacBook - hence this post, which serves as notes for myself, and may help somebody else.


It is obvious that Apple Mac support for multiple, external, displays and touchscreens is less mature than Windows.  The MacBook problems remind me of problems I had with Windows circa 1999-2002, i.e. in the past century.


The first problem was connectors: 


The GeChic has micro HDMI and mini-VGA inputs.   I have used it in the past via the "normal" HDMI to micro-HDMI cables, both from GeChic, and similar cables that I bought at Frye's or Best Buy;  and via the mini-VGA input, which is aa bit harder to find.


My 30" display was using the only HDMI port on the MacBook.   


Using DisplayLink and HDMI simultaneously on the MacBook has not worked well in the past.


Connecting a second USB display adapter has not worked well in the past.  Besides, I still need connect MacBook--USB-->BVU195--DVI--> ... to the GeChic, mini-VGA or micro-HDMI.


In my kit of cables and adapters, I had I mini-DisplayPort to DVI adapter, and  DVI to HDMI adapter, as well as my HDMI to micro-HDMI cables.   So I hooked that up:



MacBook

mini-DisplayPort

--DisplayPort-->

DisplayPort-to-DVI adapter

--DVI-->

DVI-to-HDMI adapter

--HDMI-->

micro-HDMI port

GeChic 1502I



This worked (a bit to my surprise).  And I have not yet seen the display memory overrun problems that plagued my past attempts to have a 3rd external display on my MacBook.  (Possibly because the GeChic has fewer pixels.)


After much screen blanking and resetting, the MacBook came up.


Also connected: external DCIN for the GeChic (USB caable), aand USB for the touchscreen interface.


At first I wanted to use the GeChic upside down, because the cabling was easier than way. The MacBook understood this, after the usual hassle of having to rotate the display.  (Side note: I wish that more external displays could rotate locally, as opposed to depending on software on the PC.)


Things seemed good, until I started trying to use the GeChic touchscreen.


First problem:  if my big 30" display was the "main" monitor for the MacBook, touching the GeChic moved the cursor on the big display, not on the non-mirrored display extended to the GeChic.


Second problem: the GeChic was upside down.  Rotating the display in the Mac preferences rotated the display - but not the touchscreen.    I could not find any way to rotate the touchscreen on the MacBook.


Third problem:  in these configurations the MacBook kept - not exactly hanging or crashing, although I wonder if something almost as bad was happening.  The first two or three touches worked, but then the MacBook blanked all screens, and logged me out.  I don't THINK it crashed or rebooted, but it might as well have.   


So I gave in and turned the GeChic rightside up, and rearranged the cables to reach.


Given this, it seems to be working okay.  So far.


... Nope.  I just tried touching the GeChic screen, and the same screen blank / must type password and log back in problem occurred.   It was working for a while - I could move windows around by touch, etc. -  but has stopped working.


When I thought that all was working okay, I was going to pontificate on how I have never seen such problems with Windows - somehow windows managed to recognize that the touchscreen and display came from the same device.  But not Mac.

I tried connecting the GeChic via HDMI, and the 30" display via the DisplayPort-DVI-HDMI 2 adapter kluge.  This may have worked - the MacBook did not do that funny not-quite-a-crash when I touched the GeChic.  But the 30" monitor could not be driven at full resolution across DVI.

I happened to have with me my home Thunderbolt/DisplayPort-to-dual-DVI+USB adapter. No avail - still got the funny not-quite-a-crash when I touched the GeChic.

Thinking, I wondered if the problem might be that the GeChic touchscreen USB connection was being routed through a USB hub (an IOGear 7-port USB 2.0 hub).  Perhaps there is some sort of ID from the GeChic USB that can be correlated to a similar ID on the HDMI input, that somehow got filtered by the external USB hub.  Seems unlikely, since the Mac probably has an internal USB hub inside its case.   But I tried it anyway - connecting the GeChic USB touchscreen output directly to the MacBook.     Failed first try, using a thin standard USB A to microUSB cable.   Switched to the heavier 2 standard USB A to microUSB cable that GeChic provided.

... Success.  So far.  15 minutes. ... Nope - after a while, touch the screen and the MacBook does that funny not-quite-a-crash again.

(At least I didn't lose the notes I have typed into this blog.)

(Does anyone at Apple realize how annoying it is that display preferences ungathers every time the display configuration changes?  Why not put a gathered window on each?)

---

Finally, I did what I should have done first thing: I plugged the GeChic into my MacBook by itself.  No other displays.  Same symptoms.

I was misled by it "almost" working - by the display working immediately, and by the touchscreen working at first -- but then producing "not quite crashes" later.

I was misled by my familiarity with Mac multi-display problems and workarounds.  I wasted time working around incorrect guesses as to the root cause.

Plus, I was misled by my windows experience, where I have plugged in any number of touch devices - Wacom tablets, Cintiq, etc. - with no problem.  Not so for Apple, apparently.

I had already googled GeChic and Mac.  I was misled by reports that it worked; also, GeChic themselves said that it worked.   Later googling, after wasting all of that time, reveals that Macs are notorious bad at touchscreens: Apple's attitude seems to be "iOS=>touch, Mac=>no touch".   There are third party companies that provide $$$ Mac touchscreen drivers/

'via Blog this'

1 PEP 308: Conditional Expressions

1 PEP 308: Conditional Expressions:  x = true_value if condition else false_value"



I am vindicated!!!!



Or at least I am following in Guido's footsteps without noticing it.



More and more, I have been using  R := A if Cond else C

in pseudocode, etc., because it reads better than

R:= if Cond then A else B



Python does the same.





I must admit, however, that I wish that both versions were available - it depends on whether you want to emphasize the condition of the value.



For multiway if expressions



R := if C1 then V1 elsif C2 then V2 elsif ... else Ve



looks better than



R := V1 if C1 elsif C2 then V2 elsif ... else Ve



although I think that both have value, again, depending on whether you want to emphasize the condition or the value.



Also, often the conditions are error conditions, and the primary condition is the negation of all the rare error conditions:

R := if rareC1 then rareC2 

        elsif rareC2 then rareV2 

        elsif ... 

        else Most_Common_V_Else

This is the equivalent of putting the default case at the top of a switch statement.

Can we come up with a syntax that allows this?

R := Most_Common_V_Else

        if rareC1 then rareC2 

        elsif rareC2 then rareV2 

        elsif ... 

        else /*no value?*/

R := Most_Common_V_Else

        if none of the following (

           if rareC1 then rareC2 

           elsif rareC2 then rareV2 

           elsif ... 

           /* bit no else */

        )

 

'via Blog this'